1. Make it right.
2. Make it work.
3. Make it fast.
Once code works, it's all too easy to move on and leave it the way it is. It also usually takes significantly more time to take code that works but is god-awful and clean it up than to take code that is well-factored and make it work correctly. The former usually involves rewriting large fractions of the code (frequently breaking it somehow in the process), while the latter usually just requires minor tweaks after automated testing.
"Make it right, then make it work" seems to me to take about twenty percent more effort than just "Make it work", but half the effort of "Make it work, then make it right." And dramatically less effort as the time between "making it work" and "making it right" grows.
Very true, but it can sometimes be hard to convince the boss that we need to go to step 2 when the system is working. I try to apply at least some parts of "right" the first time.
1. Make it work
2. make it right
3. make it fast