The Right Way To Build Software

As far as I can tell, there is exactly one way to write software that reliably produces working systems.

Before we get to what way that is, let’s first define some common properties of non-working software systems:

1. Changes take much longer to implement than expected; time estimates often end up being pure guesswork and deadlines slip
2. The system is unreliable; it has poor performance, crashes unexpectedly or malfunctions in other ways
3. It frequently has bugs and regressions

In my experience, these properties are usually caused by either over-engineering or under-engineering.

Under-engineering is when problems in the code are not fixed at the same rate as they appear. (Problems can range from architectural issues to poor performance) Often this is caused by either an inexperienced team that do not have the know-how required to spot and fix problems, or a team that has been under pressure for an extended period of time.

Over-engineering is usually caused by too much up-front design; the designers of a system anticipated one type of problem to occur, and designed their system around that. As the system evolved, it turned out that the anticipated problem was either irrelevant, or a much smaller problem than the actual problems they encountered. The architecture that supports the expected problem is now a barnacle that causes drag on the project.

It goes without saying that ignoring problems will cause more problems over time. What is less obvious is that if you try to fix problems you don’t have, the fix becomes the problem.

The key to avoid either of those traps is to solve problems just in time:

1. Start with the simplest solution you can get away with
2. Develop it incrementally
3. Solve problems as they appear; not sooner, not later

This might sound controversial, but I have never seen any examples that contradicts this observation. I’m not saying there might be exceptions—such as rocket control systems, etc.—but none that I’ve seen personally. If you have any experiences to the contrary I would love to hear them!