3 ms·

Beware of the dreaded Second System Effect. As in your second system is assured to be a disaster because you think you know enough but never really do. The pr

Beware of the dreaded Second System Effect. As in your second system is assured to be a disaster because you think you know enough but never really do. The practice of rewriting everything once assures that you will eternally experience the Second System Effect. OK to rewrite the really bad stuff that has a high density of bugs. OK to adapt your architecture if it really doesn't fit the problem domain you are discovering and you really can make it simpler. OK to clean up basically ugly code that neither you nor others can easily understand. The important thing is to have a good reason to rewrite besides "I always do it that way." Always rewrite from scratch on principle? This is the path to madness, failure, project overruns, and downright disasters. That is unless you are very very lucky. Luck helps but good software is not produced by luck.

elviejo 18y ago
Not entirely true, even Brooks on "The Mythical Man Month" suggests to Plan to throw one away. So the suggestion isn't "the path to madness". The way to avoid the Second System Effect is simply to make a commitment not to develop new features on the rewrite. This second system will do the same as the first one except the code will be better. An example of a successful project that did this is Subversion they pretty clearly said that they wanted to Create a CVS equivalent with certain annoyances corrected. That clear purpose and definition helped them avoid feature creep.
dreish 18y ago
My understanding was that the second-system effect refers specifically to a junior programmer's second project, not the second iteration of any given project. In any case, the solution proposed was not to avoid ever designing a second system, but to be mindful of this danger while doing so. (Not that I'll follow this advice either. Deliberately forcing myself to solve the same problem the same way more than once would drive me nuts.)

elviejo 18y ago

Not entirely true, even Brooks on "The Mythical Man Month" suggests to Plan to throw one away. So the suggestion isn't "the path to madness". The way to avoid the Second System Effect is simply to make a commitment not to develop new features on the rewrite. This second system will do the same as the first one except the code will be better. An example of a successful project that did this is Subversion they pretty clearly said that they wanted to Create a CVS equivalent with certain annoyances corrected. That clear purpose and definition helped them avoid feature creep.

dreish 18y ago

My understanding was that the second-system effect refers specifically to a junior programmer's second project, not the second iteration of any given project. In any case, the solution proposed was not to avoid ever designing a second system, but to be mindful of this danger while doing so. (Not that I'll follow this advice either. Deliberately forcing myself to solve the same problem the same way more than once would drive me nuts.)