4 ms·

When I program something new and challenging, whether I want to or not, I follow Kent Beck's pattern[0]: “Make it work, make it right, make it fast.”. It seems

When I program something new and challenging, whether I want to or not, I follow Kent Beck's pattern[0]: “Make it work, make it right, make it fast.”. It seems unavoidable. [0]: https://en.wikipedia.org/wiki/Kent_Beck https://en.wikipedia.org/wiki/Kent_Beck

IshKebab 2y ago
I dunno if you can always do them in order. I've seen so many projects fail because they left "make it fast" until the very end ("but premature optimisation!") and then found they'd written tens of thousands of lines of code using a language or architecture that was fundamentally slow, and making it fast would require a full rewrite. I think it's fine advice in some circumstances but like so much coding advice the real skill is not knowing the advice, it's knowing when to apply it.
- mewpmewp2 2y ago
  Out of curiosity which projects were those? It must be a very specific use-case, because usually I would see languages usually considered worst for performance being able to scale really, really far. In 95% cases it's usually database being the bottleneck rather than whichever coding language you chose.
  - IshKebab 2y ago
    The main one I'm thinking of was a silicon verification system written in Python. Not the only reason the project failed but the fact that it was so janky and slow definitely helped slow progress to a crawl. It didn't have a database. Speaking of Python, I also recently wrote a tool in Python that was getting a little slow and bloated - I rewrote it in Rust and managed to reduce the runtime by 40x and memory use by 3x. This one wasn't mission critical but you can see the scale of the issue. And no there wasn't any realistic way I could have found a hot spot and just written that part in another language. That rarely helps in my experience.
bluGill 2y ago
If edison had spent some more time thinking he would have perspired a lot less. Too often there is no path from one to the next other than starting over. If you have the wrong algorithm your existing tests won't help much as the likely have wrong edge cases.

IshKebab 2y ago

I dunno if you can always do them in order. I've seen so many projects fail because they left "make it fast" until the very end ("but premature optimisation!") and then found they'd written tens of thousands of lines of code using a language or architecture that was fundamentally slow, and making it fast would require a full rewrite. I think it's fine advice in some circumstances but like so much coding advice the real skill is not knowing the advice, it's knowing when to apply it.

mewpmewp2 2y ago
Out of curiosity which projects were those? It must be a very specific use-case, because usually I would see languages usually considered worst for performance being able to scale really, really far. In 95% cases it's usually database being the bottleneck rather than whichever coding language you chose.
- IshKebab 2y ago
  The main one I'm thinking of was a silicon verification system written in Python. Not the only reason the project failed but the fact that it was so janky and slow definitely helped slow progress to a crawl. It didn't have a database. Speaking of Python, I also recently wrote a tool in Python that was getting a little slow and bloated - I rewrote it in Rust and managed to reduce the runtime by 40x and memory use by 3x. This one wasn't mission critical but you can see the scale of the issue. And no there wasn't any realistic way I could have found a hot spot and just written that part in another language. That rarely helps in my experience.

bluGill 2y ago

If edison had spent some more time thinking he would have perspired a lot less. Too often there is no path from one to the next other than starting over. If you have the wrong algorithm your existing tests won't help much as the likely have wrong edge cases.