Hacker News Reader

Comment by f2f | Hacker News Reader

ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.

"allowed to drop functionality", as used by you, is a strawman -- the team _added_ functionality to the part they were rewriting without incurring the wrath of the second system. sure, the line counts are off, but your argument does not stand in the general.

View on HN

If I remember Brooks correctly, second system syndrome does not refer to all successor systems, and frequently complex/over-built systems spawn elegant ones in turn (oversimplifying a bit, but MULTICS -> UNIX springs to mind). I seem to recall Brooks regarding this as cyclical, with leaner third systems spawning bloated fourth systems, and so on.

i was referring to recent examples such as python 3.0, perl 6, or even, say, apache 2.0. eventually they were usable, but the blood sweat and tears involved did not make for cute blog posts such as the one we're commenting on.

I think a component in a service oriented architecture would lend itself more cleanly to reimplementation, with less chance for "Second System Syndrome", because you still have an api contract you are responsible for.

I think a "released" software, like those you mentioned, would be somewhat more likely to become a stereotypical "second system".

>ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.

And the reason was overly ambitious rewrites of huge and complex codebases.

For simpler stuff and especially when cutting down on feature bloat, rewriting is fine.

There's a phrase about rewrites, by the same guy that coined the "second system syndrome": "plan to throw one away".

Reply on news.ycombinator.com