Why do we create temporary solutions?
Usually, the culprit is an urgent task. Sometimes, it’s an internal task for developers—to create a missing tool for the development chain. Other times, the task is external, user-oriented, such as a workaround to compensate for missing functionality.
In most systems and teams, you can find a module that somehow stands out in the system. It is considered a draft version, and it will need to be redone later because it does not meet the standards and rules that the rest of the code lives by. You will definitely have to hear developers’ complaints about this. The reasons for the appearance of such code can vary, but the main reason for the emergence of intermediate solutions is their usefulness.
However, interim solutions have inertia (or a moment of inertia, if you prefer). There is already a temporary solution—extremely useful and widely accepted—so there is no urgent need to create something in its place. When deciding which actions will most increase the value of the product, a project stakeholder will find many tasks with higher priority than refining the temporary solution. Why? Because the temporary solution already exists, it works, and it is accepted. Its only visible drawback is that it does not meet the chosen standards and rules, but, except for some niche products, this is a weak argument for change.
That’s how a temporary solution remains. Forever.
And if the temporary solution becomes a source of problems, it is unlikely that the task of bringing it in line with accepted quality standards will be set during the repair. So what to do? A quick interim change to the temporary solution often resolves the issue and satisfies everyone. It has the same advantages as the original temporary solution, it’s just… newer.
Does this pose a problem?
It all depends on the project and your personal interest in maintaining the quality standard of the finished code. If there are too many temporary solutions in the system, its entropy or internal complexity increases, and the ease of maintenance decreases. However, perhaps the first question to ask should be a different one. Don’t forget that we are discussing a solution. You may not be happy with this solution yourself – and neither is anyone else likely to be – but the incentive to revise the solution is weak.
So what can be done if this is a problem for us? 1. First of all, avoid temporary solutions. 2. Change the factors influencing the project manager’s decision. 3. Leave everything as it is.
Let’s consider these options in more detail: 1. In many cases, abandoning a temporary solution is unacceptable. There is a real problem that needs to be solved, and it turns out that the standards are too strict for this. One could try to change the standards – a commendable, albeit labor-intensive achievement – but it will take time, and the problem needs to be addressed right now. 2. These factors are rooted in the project’s culture, and it resists forced changes. Success can only be achieved in very small projects – especially when working alone – and if one can tidy up without asking for permission. Success is also possible when the project’s code is so messy that it noticeably slows down work, and everyone agrees that some time should be spent on tidying up. 3. If the previous option does not work, the status quo is maintained automatically.
Among the many solutions you create, some will be temporary and mostly useful. The best way to get rid of temporary solutions is to make them redundant by offering more elegant and useful solutions. And may you have the peace of mind to accept what you cannot change, the strength to change what you can, and the wisdom to distinguish one from the other.