The 3rd version syndrome
… a sometimes fatal phenomena that occurs within nearly every software company or IT department Here’s the scenario …
1st Version
– Sometimes a prototype gone to market or a Phase I. Customer or user feedback occurs, (a good thing), and the request for more or different features come pouring in. The first version is modified, and augmented to meet the need.
2nd Version
– Contrary to the plan to “finish” the 1st version, the 2nd version becomes a modification and evolution of the first version. While the 2nd Version is often a tremendous success, it’s sometimes a hodge-podge of added functions and cannot sustain the long term evolution of the product.
3rd Version
– Not always at the 3rd version, sometimes the 4th, 5th, or 6th, but inevitably there comes a time that the almighty “re-write”, “re-architecture”, “re-something” needs to occur in order to continue with enhancements, new capabilities, increased speed, improved UI, etc. etc.
The re-write begins
– The odds are overwhelmingly in favor of the re-write taking longer and costing more than expected. There are a variety of reasons, for example;
- The original authors may not be available, and therefore their thinking will need to be re-invented.
- The re-write is more than a re-write and contains a large number of new features.
- The false assumption that since the current version exists, the requirements are well defined.
- The false assumptions about how long it will take to generalize prior one-off implementations.
- The lack of knowledge or documentation about those special cases built into the current version.
- False assumptions about efforts to implement using a new language and/or architecture.
- The desire to design and implement a new version that will last for a very long time.
OOPs
. Bad enough that the schedule for the “new and improved version” slips, but to compound the problem, all work on the old version was stopped as there was no sense working on the old version when the new version was soon to come out. Knowing now that the new version is delayed, the scramble begins to see if the old version can be resurrected and incrementally changed to address the immediate needs and hold market share or satisfy corporate requirements.
Too Late
, the competition already came out with a new version … not as good as your “still to be delivered new version”, but better than your existing version. You’ve lost the lead.
The Takeaway
, There are two. The first is that the current version usually has a lot more life in it then one thinks, proven by numerous desperate and successful acts of enhancing it when the new version was delayed. Second, and most important, NEVER stop working on your current version before the new version is done and available to customers. While this may cost a little more as you have two efforts going on, it’s a low cost insurance policy against the catastrophe that occurs when the new version is delayed.
