Third Version Effect

Claimer: I first posted this information on ThirdSystemEffect, but what I was trying to say was ThirdVersionEffect. If you feel like this is a better name, we can keep it, but please verify that the MythicalManMonth uses this exact words, because they seem to be misleading. -- GuillermoSchwarz

The first version of any software usually works but is a big mess inside. Most functionality has been postponed, that's why they were able to deliver in the first place.

If your project is in its second version, it will be better.

When your project is finally the third version, then it will probably succeed in a clean elegant way, because you will have GetTheRightAbstraction.

Since the first version is successful, they decide to create a second version. The second version, to be successful, needs a lot of refactoring and some rewrite to GetTheRightAbstraction. The right abstraction is the abstraction that permits to easily add the much needed new functionality.

The same happens with the second version: It is better than the first one, but only so much better. A third version is needed. This time, there is more refactoring and more code written from scratch. You GetTheRightAbstraction this time, because you have so much hindsight. The third version usually is easier to understand to its developers, but not as easily understood by new developers: they would have preferred the first version because they have no hindsight. You can't skip the earlier versions - they are required to get hindsight. You must really try hard to get the first and the second version to work, get released and used. You must get feedback from them, then you can go on to implement the third. Is it possible that the MythicalManMonth has been replaced in practice by the MythicalManHour???

Originally written by GuillermoSchwarz

The first version of any software usually works but is a big mess inside. Most functionality has been postponed, that's why they were able to deliver in the first place.

When your project reaches the third version, it will probably succeed in a clean elegant way.

Since the first version is successful, they decide to create a second version. The second version, to be successful, needs a lot of refactoring and some rewrite to GetTheRightAbstraction. The right abstraction is the abstraction that allows the much needed new functionality to be added easily.

The same happens with the second version: It is better than the first one, but only so much better. A third version is needed. This time, there is more refactoring and more code written from scratch. You GetTheRightAbstraction this time, because you have so much hindsight. The third version is usually easier to understand by its developers, but not as easily understood by new developers: they would have preferred the first version because they have no hindsight. You can't skip the earlier versions - they are required to get hindsight. You must really try hard to get the first and the second version to work, get released and used. You must get feedback from them, then you can go on to implement the third.

This is not related to the SecondSystemEffect, discussed by FredBrooks in The MythicalManMonth. Roughly the SecondSystemEffect says: If your project is the second unrelated system for most of your designers, it will probably fail outright, because your designers feel confident and therefore they are not careful enough. If it doesn't fail, it will be bloated, inefficient, and icky.