(^108) 97 Things Every Programmer Should Know
The Longevity of
Interim Solutions
Klaus Marquardt
WHY DO WE CREATE iNTERiM SOLUTiONS?
Typically, there is some immediate problem to solve. It might be internal to the
development team, some tooling that fills a gap in the toolchain. It might be exter-
nal, visible to end users, such as a workaround that addresses missing functionality.
In most systems and teams, you will find some software that is somewhat segregated
from the system, that is considered a draft to be changed sometime, that does not fol-
low the standards and guidelines that shaped the rest of the code. Inevitably, you will
hear developers complaining about these. The reasons for their creation are many
and varied, but the key to an interim solution’s success is simple: it is useful.
Interim solutions, however, acquire inertia (or momentum, depending on your
point of view). Because they are there, ultimately useful and widely accepted,
there is no immediate need to do anything else. Whenever a stakeholder has
to decide what action adds the most value, there will be many that are ranked
higher than proper integration of an interim solution. Why? Because it is there,
it works, and it is accepted. The only perceived downside is that it does not fol-
low the chosen standards and guidelines—except for a few niche markets, this
is not considered to be a significant force.
So the interim solution remains in place. Forever.
And if problems arise with that interim solution, it is unlikely that there will be
provision for an update that brings it into line with accepted production qual-
ity. What to do? A quick interim update on that interim solution often does the
job, and will most likely be well received. It exhibits the same strengths as the
initial interim solution...it is just more up to date.
Is this a problem?
The answer depends on your project, and on your personal stake in the produc-
tion code standards. When the system contains too many interim solutions, its