3 ms·

Make it run -> make it right -> make it fast

by Dowwie 9y ago

mannykannot 9y ago
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.
twic 9y ago
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.
- d3ckard 9y ago
  If it currently takes time T, then it already runs and probably runs right, otherwise you likely wouldn't care about cutting time. Rule still stands.
  - twic 9y ago
    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.
- saltedmd5 9y ago
  This depends on the definition of "right," though - if "close enough" really is enough, then "close enough" _is_ right. "Right" doesn't necessarily mean "precise."
darioush 9y ago
I like: modify your setup so if it runs it is right and fast.

Make it run -> make it right -> make it fast

by Dowwie 9y ago

Make it run -> make it right -> make it fast

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.

twic 9y ago

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.

d3ckard 9y ago
If it currently takes time T, then it already runs and probably runs right, otherwise you likely wouldn't care about cutting time. Rule still stands.
- twic 9y ago
  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.
saltedmd5 9y ago
This depends on the definition of "right," though - if "close enough" really is enough, then "close enough" _is_ right. "Right" doesn't necessarily mean "precise."

darioush 9y ago

I like: modify your setup so if it runs it is right and fast.