I generally aim for 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 als

I generally aim for 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.