I am often asked why I insist on building software that is simple and easy to understand (both for ourselves and for others), and above all, maintainable. Many of us who develop software professionally still don’t have a clear grasp of some essential concepts. For example, a maintainable design has nothing to do with designing something that is impossible to modify, debug, or evolve. Even if both work, the first makes better use of the work we’ve done, while the second sends software into production half-dead and with little chance of recovery.
Still, we find it hard to recognize the relationship between simplicity and ease of maintenance.
Maintainable (a mantra-like word in The Programmer’s Black Book) doesn’t mean trivial, or so easy that a beginner can understand it at first glance without any effort. It means coherent: an efficient design that makes future changes easier and allows related new requirements to be accommodated at an acceptable cost.
Unlike a best-selling author, who earns royalties based on sales when a book does well, the success of a software product depends in part on whether it can evolve, be changed, and be maintained easily.
In Code Simplicity—a book I recommend even if you don’t read a single line of code—you can find genuinely revealing statements that the author tries to distill into common laws governing the development of any software.
One of the author’s claims is that “the ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces.”
When I read that, I thought about how long I had sensed this relationship without being able to express it so masterfully. That is one of the book’s strengths: it brilliantly distills real truths that, although easy to understand, are not so easy to internalize and make part of our DNA as professional programmers.
Indeed, it seems fundamental, but keeping it in mind in our everyday work is not so straightforward.
If we want to build maintainable software, the key is to make each of its parts simple. The choice isn’t between simplicity and maintainability; the two concepts are closely connected (and their relationship is proportional).
Why should we care about making what we develop relatively easy to maintain? Simply because any software product—whether it is sold under a license, built internally for our company, or even a personal project—will be maintained for much longer than it took to develop. What’s more, the more successful it is, the more changes and improvements people will ask for. A product’s rate of evolution can therefore also be considered a sign of its success.
I always use the same example: would we buy a car that is almost impossible to repair or very difficult to change the oil in?
Do we really keep this in mind when we write line after line of code?
The concepts of simplicity and ease of maintenance are easy to understand, but what is harder is keeping them in mind in our daily work. Nobody can write clean code on the first try. To get there, we have to seek a simple solution through refactoring, continuously reviewing what we’ve already done, and so on.
An ingenuous developer will simplify when it suits them, rather than systematically, and won’t worry about whether their work can be maintained or debugged easily (they don’t realize it may come back to bite them). A naive programmer only cares about making what they’re working on function at any cost, forgetting that this is a case of short-term gain and long-term pain…
If our software is maintainable, we are laying the foundations for its success. If it isn’t, it will be born half-dead and eventually become a failure and a source of dissatisfied customers. We achieve maintainability by making sure the individual parts of our product are simple.