The Longevity of Interim Solutions

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 7: Line 7:
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 the update 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.
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 the update 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 stays in place. Forever.
+
So the interim solution remains in place. Forever.
-
And if problems arise with that interim solution, there will be no plan for an update that follows the standards. What to do? A quick interim update on that interim solution often does the job. And no surprise: it will be well received. It exhibits the same strengths as the initial interim solution, but is now more up to date.
+
And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. 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... but is now more up to date.
Is this a problem?
Is this a problem?
-
First of all, remember that this is a solution. It may not be your preferred solution — actually nobody might think of it as a preferred solution — but the motivation to remove this solution is too weak.
+
First of all, remember that this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to remove this solution is too weak.
What can we do?
What can we do?
-
# Do not create interim solutions in the first place.
+
# Avoid creating an interim solution in the first place.
# Change the forces that influence the decision of the project manager.
# Change the forces that influence the decision of the project manager.
# Leave it as is.
# Leave it as is.
Line 23: Line 23:
Let's examine these options more closely:
Let's examine these options more closely:
-
# This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endevour with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
+
# This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
# This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
-
# This automatically applies if B does not.
+
# This automatically applies if the previous option does not.
Welcome to the cynicism of project veterans.
Welcome to the cynicism of project veterans.
 +
 +
By [[Klaus Marquardt]]
 +
 +
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 +
 +
 +
Back to [[97 Things Every Programmer Should Know]] home page

Revision as of 17:15, 31 January 2009

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 tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality.

The implication of an interim solution is that it is not fully integrated into the production code, or does not follow the standards and guidelines that shaped the rest of the code. The reasons 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 the update 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. Forever.

And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with acceptable production quality. 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... but is now more up to date.

Is this a problem?

First of all, remember that this is a solution. It may not be your preferred solution — it is unlikely to be anybody's preferred solution — but the motivation to remove this solution is too weak.

What can we do?

  1. Avoid creating an interim solution in the first place.
  2. Change the forces that influence the decision of the project manager.
  3. Leave it as is.

Let's examine these options more closely:

  1. This does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. Apart from starting a tedious endeavor with possibly no positive outcome, it will only be effective for some future interim solution, not for yours.
  2. This requires that the project culture changes. This can be successful in very small projects, in particular if it's just you, and you just happen do clean the mess without asking in advance. This can also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
  3. This automatically applies if the previous option does not.

Welcome to the cynicism of project veterans.

By Klaus Marquardt

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools