Coding is a small part of a developer job
Here is how developers estimate the time it takes to build something: they think about the time it should take to do it, and then, they multiply that number by 3, well, by 4 actually to be safe. They know it will take them longer than expected for the some reasons such as:
- the task at hand isn’t fully spect out and/or it’s not fully understood
- the customers don’t necessarily know what they want; they have an idea they need to try out first
- someone, not sure who, will interfere at some point
- an issue or two will arise: some missing data, incompatible libraries, a mistake in the initial requirements, someone important to the project leaves, etc.
Basically, at least 66% of the time is spent doing something else than coding.
What does take the bulk of the time?
In short, the bulk of the time is spent on understanding constantly-evolving requirements. That’s not all though. That would be too easy ! Any project comes with someone wanting the job to be done, someone paying for it, someone checking it, someone using it… Many projects come with people trying to avoid getting their part of the job done (for a wide range of good and terrible reasons). Most projects come with some history. Some projects come with team(s) with too few, or even worse, too many people for the job. All of these conflicting forces end up in the final product somehow; they end up in the code.
Here is a more concrete idea of where the time goes:
The bits in red are the “coding” bits. It’s indeed a small part; even with many iterations.
Small but critical part
While coding is a small part; it’s a critical one.
With a poor user experience, people complain but might stay. A poor design makes your product look amateurish and/or cheap, but it won’t stop anyone from using it. Poor documentation won’t matter if everything is self-explanatory. Even poor customer service is tolerated in some cases. On the other end, if the code breaks or is just extremely slow, no one on Earth will use your product.
Code quality slowly but surely evolves as a project grows. Every project starts nicely. It’s maintaining and even improving it while understanding the requirements that matter. That’s because code has an exponential impact on every following steps.
Good VS Bad code scenarios
With a high standard, at every iteration, the code, the database, the technical documentation all become clearer and clearer. With consistency (in naming, coding patterns, etc.), the more a developer works on a project, the faster he gets at adding or updating features. That growing understanding (of the technical stack and of the business) helps with building confidence and all communications (often removing the need for intermediates).
With a low standard, at every iteration, the code becomes more and more messy. Developers become more and more nervous and their communication gets unclear. Each feature takes longer to build than the previous one. Technical debt grows exponentially; it starts slowly but quickly gets out of control.
Good code is vital to any project. It’s like your liver. Not working code means the sudden death of a project. Increasing technical debt means that the project will die slowly. Good code means that the project can work; it then depends on other things.
How to keep your code “good” then
Arguing for pure functional VS oriented-object; framework A VS B is often pointless. Most decisions are subjective and contextual. Even with a list of 100 best practices, you can still easily make a mess. Since requirements constantly evolves, refactoring is the key. To enable refactoring, you need a way to check that the code keeps working as expected. Last but not least, collaboration beats solo work.
Therefore, in my opinion, the only sane way to preserve the code quality is by:
- having automated tests so the code can be refactored with ease and confidence
- having more than one person working critical parts of the code to avoid dumb mistakes and to share knowledge in the team
- regularly refactoring the code to keep it up to the task: all developers involved must be happy with it
If all of this is done, coding will remain a small part and be considered trivial. If it’s not, it will grow and will eventually get out of control.