Making it run right is usually the hard part. I say 'run right', because if there is an assumption (explicit or tacit) that 'make it right' is a matter of relatively small incremental fixes to running code that is fairly close to being right, then this aphorism is coy about where the hard part gets done.
I am taking 'right' to mean 'correct', and not some lesser metric of quality, or an aesthetic preference.
For those cases where making it fast is the hard part, one could make the same argument, perhaps even more clearly. Having something that runs, but which uses an algorithm that will never be fast enough, could be the first step down a long dead-end.
This is good advice in general, and so it amuses me when i come across problems which invert this order. Now and then, you can say "if we could do this thing that currently takes time T in T/100, it would be a game-changer" - it would enable whole new approaches, businesses, etc. In that case, your primary goal is to make it fast, and if often doesn't matter if it crashes, fails, or gets a slightly wrong answer 10% of the time, so you start by making it fast, then improve the code, then work on the improved code to make it reliable.
No. It might take someone else time T to do it, and we don't do it at all. It might take another program, whose codebase we are not going to touch, and which does it in a different way, time T to do it. In the cases i am thinking about, this was a new program, written from scratch, which did not go through a "make it right" phase before being made fast.
