The Longevity of Interim Solutions

From WikiContent

Revision as of 13:21, 25 November 2008 by Kmarquardt (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Why do you create interim solutions?

Typically there is some immediate problem to solve. This may be internal to the development team, some tooling that fills a gap in the tool chain. This might be external, visible to end users like some workaround that fixes a missing functionality.

The interim solution implies that it is not integrated in the production code, or does not follow the standards in some other way. Reasons may be many (maybe we discuss some of that here).

Now the key factor to the success of the interim solution is: it is useful. This includes functionality as well as accessibility.

No comes the sustaining momentum of interim solutions. Because they are there, ultimately useful and widely accepted, there is no immediate need to do something else. Whenever a project manager (or product owner, choose your preferred role definition and vocabulary) has to decide which activity adds the most value, there will be many that are rated higher than the update of that interim solution. Why? Because it is there, it works, and it is accepted. The only downside is that it does not follow the (selected or imposed) standards - and this is hardly an important force, except for a few niche markets.

So the interim solution stays 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? Just quickly do an interim update on that interim solution that does the job. Surprise: it will be well received. It shows the same strengths that the intial interim solution had, plus it works even better.

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 soltuion - but the forces that would remove this solution are too weak.

What could you do?

a. leave it as is. b. change the forces that influence the decision of the project manager. c. do not create interim solutions in the first place.

Let's take a look at these actions. C - 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 in changing the standards. Besides that you start a tedious endevour with possibly no positive outcome, it will only be effective for some future interim solution, not for yours. B - 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 visibilly stalled and some time for cleaning up is commonly accepted. A - automatically applies if B does not.

Welcome to the cynism of project veterans.

Personal tools