Third System Effect

Claimer: I first posted this information in this page, 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

Brooks did use the exact words "SecondSystemEffect" (see citation I added to that pageg). The phrase "ThirdSystemEffect" is widely used (google search "third system effect" here and either explicitly attributed to him, or implicitly by talking about it in the same breath as the "second system effect", whether Brooks himself used those words or not, e.g. by Eric S. Raymond in The Art of Computer Programming: (who talks about both the 2nd and 3rd apparently without attributing either).

Brooks himself, in his chapter "The Second-System Effect", discusses the third system effect without explicitly naming it, I guess:

Clearly an architect who has already gone through his second system already will automatically have learned from experience what to do with his third system, that Brooks suggests should be a matter of discipline otherwise.

Earlier in that chapter he said "When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable." [talking about avoiding the over-design that the SecondSystemEffect leads to]

I've never read TheMythicalManMonth, but the paragraph below insists on ThirdSystemEffect.
This is the sequel to the SecondSystemEffect, discussed by FredBrooks in The MythicalManMonth. You can't rename it, this is what FredBrooks called it; it's a famous phrase.

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 the second system for most of your designers, then it will probably fail outright. If it doesn't fail, it will be bloated, inefficient, and icky.

When your project is finally the third system for most of your designers, then 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 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.

This sounds like WittgensteinsLadder.
Is it possible that the MythicalManMonth has been replaced in practice by the MythicalManHour??

RefactorMe: Someone moved parts of this to ThirdVersionEffect without cleaning up behind.

EditText of this page (last edited October 24, 2005) or FindPage with title or text search