I once heard an anecdote that the 3rd version of a system is when it starts to become really efficient.
The 1st version is rife with hacks and inefficiencies, but it works.
The 2nd version builds upon all the learnings of the first version, but is bloated because every little lesson learned is applied.
The 3rd version is where the experience and data gained from the first two iterations really starts paying off. The code is more efficient and the team knows what is truly important and what isn't.
P.S. Has anyone else heard this anecdote before as well? I've tried tracking down its origin to no avail.
I wonder about this style of thinking. In particular, the distinction between making it work and making it right.
I've read The Pragmatic Programmer, and early-on, it mentions "broken windows" principle -- fix errors as soon as you notice them, or else they'll get more difficult for you to fix as time goes by. And like broken windows are like a green-light for a neighborhood to decline, unfixed hacks similarly invite poor quality code.
In practice, do "working" and "working well" end up being sort of the same as suggested by the broken windows principle? Or Is "make it work" refer to making a quick prototype, and "make it right" refer to filling out substantial functionality?
>>I wonder about this style of thinking. In particular, the distinction between making it work and making it right.
The reason for this style of thinking applies to projects that you don't really have a clear path on how to implement them. A good example would be building a humanoid robot. Along the way you learn what works and what doesn't and you end up with a project that works, sort of. Now that you have a better understanding of the problem you re-architect the entire project, if needed, to make it easier to maintain long term.
Of course, this is just a rule of thumb. You don't have to wait till the end to re-architect a project. You could treat each major sub-module as a project of its own and apply this same thinking.
Seem to recall an article posted on HN some time back called "Suffering Oriented Programing."[0] I doubt this is where the idea originated but the author does a good job of relating the principal to coding.
The 1st version is rife with hacks and inefficiencies, but it works.
The 2nd version builds upon all the learnings of the first version, but is bloated because every little lesson learned is applied.
The 3rd version is where the experience and data gained from the first two iterations really starts paying off. The code is more efficient and the team knows what is truly important and what isn't.
P.S. Has anyone else heard this anecdote before as well? I've tried tracking down its origin to no avail.