34 ms·

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 earl

by elangoc 15y ago

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?

felipemnoa 15y ago
>>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.