Chapter 54. The Longevity of Interim Solutions

Klaus Marquardt

image with no caption

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 external, 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 follow 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 follow 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. ...

Get 97 Things Every Programmer Should Know now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.