There was a time when the boss came to us and demanded that we just start coding. It was a fire, fire, aim approach that worked under some circumstances — but not when it comes to code.
Creating code is more akin to building a house — you need at least the measurements and parts planned out before you start putting it all together.
When people hear the words MVP and agile, they think to jump right in without forethought or planning. Planning how your application is going to run and get built is different from planning your entire release strategy.
You can still release in cycles for MVPs and agile implementations — but you still need to know exactly what it is you’re releasing. Contrary to popular belief, it doesn’t take that long to code once you know what your product looks like.
But first, you need to know — or else it takes twice or thrice as long to code.
Here are the minimum things you need before you start hitting the keyboard to code.
Know the shape of your data
Data shape is much more important than many businesses realize. Data is the backbone of any application. It is the reason why a particular app exists — to display and process data.
Without this, you’re simply coding water.
Knowing what the data looks like also helps you figure out how to codify your business rules. As developers, our job is to implement ways to create, read, update and delete data. Things such as sessions, persistence, and load controls are additional ancillary features to the overall purpose of the app.
The shape of data also determines how your front and back ends interact with each other. It lets us know what inputs are required and while the actual live database connections may not be created yet by the backend, the frontend can at least create mocks in a productive manner.
When your data shape is different from expected, the frontend will often need extra time to rewire in accordance with reality. The backend may also need to be rewired based on how the database is structured if it’s not already in existence.
The act of rewiring is one of the main reasons why application development often takes longer than initially anticipated. It is usually caused by a flow-on effect of not knowing what the data shape is, resulting in long term technical debt even before the project or feature is delivered.
Have a general idea of what the expected user flow is
The user flow is determined by the expected outcome for a specific set of business rules. Sometimes these business rules are not quite solidified yet. But there are some features and visual layouts that can be modularized and moved around.
By knowing how a user may traverse through experiencing your application, you are giving the development process a better chance at the creation of a steady structure. If data is the foundation of your digital house, expected user flow is like the walls and room configurations.
Have the user flow designed is like having your interiors designed. It’s easier to change the color and certain structures like benchtops than to reconfigure the entire walls, doorways, and structural setup.
Where is the app expected to go in the future?
It’s one thing to know your expected current state, it can also help determine certain technical debt related decisions when we’re aware of future states.
When you’re working with an MVP, it’s good to know the expected or potential trajectory, so you can make architectural and code allowances for future movement, refactoring and modularity choices against the time given.
Knowing what to expect also gives us the ability to landscape our code to meet with potential demands. It allows us to balance our current coding decisions with future load and changes.
While these future plans are not required to be set in stone, having knowledge of them makes it easier to decide on things that may persist in the long term. It also allows us to optimize for these future changes rather than try and satisfy every potential use case.
As a result, our current and future endeavors will result in higher efficiency and outputs, in part, because we have a potential forecast rather than just stabbing into a speculative crystal ball.
Final thoughts
The quality of your final delivery depends on how much you know about the expected outcome before you start coding. Most of the time, when you start coding before you know what you need to code, you end up with junk that just adds to your technical debt.
Data and its expected transformations also play an important role in determining the level of debt you can potentially experience long term. Bad data design often arises due to a lack of knowledge or understanding of the business.
Sometimes, this isn’t a developer’s fault directly but rather the business’ inability to communicate their needs before development takes place.
What businesses also need to understand that there is more than just code in software development. As developers, we are more than just code monkeys laying down bricks — even then, you still need some sort of blueprint or instructions to produce something of value.
So always begin your projects and coding endeavors with some sort of blueprint — at a minimum — so at least you’ll know exactly what it is you’re creating.
