This is all too harsh though. When you are doing something new, you aren't that sure what kind of extensibility and modularity you need internally, so you wind up over engineering and over architecting. Imagine you wanted to build a bridge without no one ever doing that before. It is an open problem, the resulting bridge might work, but it won't be pretty and probably used way too many materials, meaning it will be difficult to repair and upgrade.

But your next bridge will be better, benefiting from the experience of the previous one, and you might be able to even do some design up front for the third one that actually sticks.

Tl;dr get started on your first bridge early.

Your second bridge might not be better if this turns out to be true: http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_seco...

The error is not building the second bridge, it's trying to create a new design from the ground up rather than improving on the first one.

True, but in research it is expected. I would guess development is much more conservative.

> Reminds me of this statement by Brian W. Kernighan, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.

> A corollary is that if you are writing code with minimum repetition, you are effectively a compression algorithm, not a programmer.

I do not understand why that follows. Can you elaborate, please ?