The longer your application lives, the more likely it is to need to change. It’s as simple and emphatic as that.
I’ve sometimes been asked why I seem obsessed with programming and designing in the simplest, most readable way possible, and why we should worry now about something that may or may not need to change in the future. The question itself reveals a certain naivety about the artifacts we create in our profession.
One of the truths about our work, elevated to the status of a law, says that the longer an application, program, system, plugin, framework, and so on remains alive, the more likely it is to need changes, improvements, fixes, and so on. Law or not, I can say that no software I’ve worked on has remained unchanged for more than six months…
Do we keep this reality in mind in our day-to-day work? Do we really make a point of refactoring and improving things in small steps continuously? Do we strive to find the simplest solution to every problem?
It’s true that we can leave things as they turned out the first time we made them (after all, they work, don’t they?). But if we leave loose ends, duplication, known bugs, and a trail of shoulds behind us, a mountain will eventually build up and fall on us—or bury the product in oblivion.
All software will inevitably need to change in the future. Any product launched on the market will die if it isn’t continually renewed with improvements (continuous delivery). Any established client will almost certainly ask us for improvements or changes. No matter how much effort we’ve put into testing our code, the client will eventually find new errors or small bugs; sometimes, we’ll discover that we misunderstood a requirement. At other times, changes in the market or in the profile of the customers our software targets will determine what needs to change.
There are far too many reasons not to center our work on simple solutions. Simplicity is almost never achieved the first time; instead, through small refactorings, examining our work with tests, and improving the application as it grows, we gradually make it better in every way. We also can’t ignore that the cost of evolving an application must be as low as possible. Otherwise, we’ll be out of the market sooner than we’d like.
“Paradoxical as it may sound, programming professionally also means being willing to destroy part of the work we’ve done—precisely to improve it! If our software can’t be modified and improved easily, it will lose profitability and opportunities to compete.”