temporary choices
We are often delusional about the temporal nature of written software. After all, nothing is more permanent than temporary piece of code. We often think software should be beautiful or clever for it to exist at all. But, (rightly so) code is only as beautiful and useful as the information it outputs.
This might be because code is considered an end result, instead of a means to an end. The business needs for refactoring a working piece of a program arises usually only when the code is too difficult to work with. The more critical the domain, the greater the risks, and more difficult to take the responsibility for fatal errors.
All this shouldn’t be a problem, at least when we don’t fool ourselves. Commitment is positive, permanence can be soothing. Though excuses about time and later refactoring hopes are plentiful. Better yet, coming to terms with good enough is liberating. Always strive for better, but never forget it’s enemy (perfect).
Developers aren’t the only delusional bunch. The modifiable nature of the digital and virtual can create a hyperactive atmosphere for constant and unneeded change. Non-developers sometimes have equally crazy expectations, but arising from different sources. The malleability of digital creations is sometimes seen greater than of those in the physical world.
Modifications in the digital realm can be a matter of minutes, or take years. This is because the mechanism that provides the end result can be more complex than anything imaginable in the physical world of objects and materials. The digital is also abstract, unintuitive and invisible. Hurried requests arising from these misconceptions only add to the pile of temporary quick fixes, as time is not sufficiently allocated.
More often than we would hope for, the temporary nature of code appears as the total abandonment of the mess that is built upon the once temporary, but now permanent base. The graveyards of software are populated by mangled abominations of temporary features and quick fixes. But the sadder inhabitants are the unborn or slow infantile projects where no compromises were reached, and eventually met their premature end.
In the end, we should accept the work we do is mostly flawed, but good enough. In all it’s imperfectness, it will stick around for some time. The inferior and perhaps weird choices we witness in codebases are often made in suboptimal situations and contexts, and someone somewhere thought they would just be temporary.