I don't think the fact that someone made a second version without succumbing to second system effect disproves the adage outright; for the vast majority of new programmers it's still worthwhile advice to adhere to.
Like any principle or adage, if you are experienced enough to deeply understand the reason for it, you will know when it does or does not apply.
I've always heard of it as "third system syndrome". You screw up the first one(prototype), learn from it and build the second one(product) and then get overconfident, expand into unknown areas and repeat the process(third system).
> if you are experienced enough to deeply understand the reason for it, you will know when it does or does not apply.
You wont have that experience (or use it really) if you stop at your first system!
Seriously though, I agree, it's by definition that adages reveal truth. This one just feels so pessimistic and boring.
My version of this would be "the third system is the best one". Make it once, learn the space and the limitations of your solution. Make it second time, learn what isn't useful. Make it just right on the third try!
Postgres is truly an exception that proves the rule. "Sure, not every second system falls prey to this phenomenon, but you practically have to be Postgres to avoid it."
>Postgres is truly an exception that proves the rule.
That's not what "an exception that proves the rule" means. It means "you may walk here" implies (proves the rule) there is a rule that you can't walk elsewhere.
In any event, plenty of second systems are fine. It's ridiculously outdated advice. Any time someone replaces their Flask web app with a go or rust version, qed.
I dunno what your experience is like, but I have seen this scenario repeat itself many many times in many places: someone is rewriting something without fully understanding what the old thing did, blindly proclaiming that their rewrite won't have any of the problems of that old clunky thing, introducing new bugs and limitations in the process without adequately solving the problem the old thing was addressing.
All. The. Fucking. Time. Big companies are especially bad at this.
Seems to be a variant of the phenomenon second system syndrome is meant to describe.
> I dunno what your experience is like, but I have seen this scenario repeat itself many many times in many places: someone is rewriting something without fully understanding what the old thing did, blindly proclaiming that their rewrite won't have any of the problems of that old clunky thing, introducing new bugs and limitations in the process without adequately solving the problem the old thing was addressing.
That's not Second System Syndrome. That's Joel Spolsky's The Thing You Should Never Do.
Also, I don't think the advice is outdated at all. I've seen it happen multiple times. However, it describes a tendency to be on guard against. It's not some sort of law of the universe.
It's also not about rewriting in Go or Rust (you may be thinking of a completely different piece of advice about not doing ground up rewrites.) The second system effect is about being overconfident from the success of an initial system with limited scope, and being too ambitious in a second system.
Your meaning is not what "the exception that proves the rule" means in my experience from ~30 years ago.
In my experience, it means:
"This thing stands out to us as exceptional because it is exceptional; there is a rule which normally applies, but we tend not to notice the rule until an exception to the rule reminds us of the rule by contrast".
> Any time someone replaces their Flask web app with a go or rust version, qed
Wait... are you suggesting that replacing a flask web app with a go or rust version is in support of or against second system syndrome? That sounds like a textbook example to me - I've seen so many second versions get built mainly for the sake of a new technology that miss a lot of the original requirements that the first version solved just fine.
An "exception proving the rule" is a colloquial phrase that can be interpreted in several ways. Yours is one of them. I'm using it here as a fun way to underscore the decades of consistent greatness of Postgres[QL], and the folly of using one of the most successful open source projects in history as a counterexample to Brooks's "second system".
The word "proves" in that maxim means "tests", in much the same way that bulletproof armour once meant that the actual armour in question had withstood a bullet (and you could see the dent) or that the proof of the pudding is in the eating.
Like any principle or adage, if you are experienced enough to deeply understand the reason for it, you will know when it does or does not apply.