5 ms·

> Code should be 1) correct 2) secure 3) readable 4) elegant 5) altruist This is a great companion to the adage "Make it work, make it right, make it fast." I

> Code should be 1) correct 2) secure 3) readable 4) elegant 5) altruist This is a great companion to the adage "Make it work, make it right, make it fast." I would map "Make it work" to #1 and "make it right" to #2 - #4. I don't quite see a clear mapping with "make it fast" to any levels of the pyramid, nor #5 with any statement in the adage, though that doesn't mean there are any problems with either.

barbazoo 6y ago
Maybe "make it fast" could fall under #4 Make it elegant, as an elegant way to solve a problem could be a way that solves it more efficiently (faster) than others.
- citrin_ru 6y ago
  Depending on situation it can be part of #1 - make it work. If a GUI application instead of <200ms has many seconds response time it kind of work, but it depends. I would not use a mail client if it takes a few minutes to open an IMAP folder or a message. But I'm OK with waiting much longer when I'm compressing a multi gigabyte file. If a backend change increases resource usage and now you need 3x more servers (VMs e. t. c.) it kind of work, but can push the project out of the budget ...or it can be a killer feature which would be worth to spend money on.
- Firadeoclus 6y ago
  Mostly I'd agree. It could also fall under #5, as a trade-off between developer time and user time. And sometimes #1, if speed is an essential requirement.
- 908B64B197 6y ago
  Yes. High performance code is a world of it's own. Readability and elegance is going to be pretty different in that particular domain anyways. But 95% of code doesn't need the absolute best performance anyways.
nvader 6y ago
I am partial to the formulation, "Make it correct, make it clear, make it concise, make it fast. In that order." - Wes Dyer
- auslegung 6y ago
  When I think of “make it work”, I think, “do any hackey thing you need to to get it to work”. Then in the next step, “make it right“, I refactor and clean up. It’s much like writing, where the advice is to write without censoring, then edit later. I think the idea is it’s always easier to edit something that exists, rather than write something correct the first time, or at least try to make it correct the first time. That being said, when I read your quote where it first says “make it correct”, I would skip the first step I mentioned above, which is a very important step. What are your thoughts?
bironran 6y ago
> Correct: ... Is it performant enough for this use case? I completely agree with that definition of correct. Code should be performant _enough_ for the use case. It shouldn't strive for the unachievable "infinite performance" or "endless scalability". It should do well now and in the next performance / growth cycle (usually measured in months to a low number of years unless you're in hyper growth). However I disagree with "Secure" being on a different level than "Correct". Or rather, the "release" line passes over the secure. I may not be happy with the structure of the code, but I will never knowingly release insecure code or allow such code to be released if I can help it. The impact of security issues to the bottom line is usually far greater (in both immediate and future terms) than the impact of any non-data-loss inducing functional issue. -- addendum --- Also I miss "being evolution ready" (future proofing). Sometimes you give up on some of the other aspects to make sure your code (and the data it governs) can be evolved should the need arise.

barbazoo 6y ago

Maybe "make it fast" could fall under #4 Make it elegant, as an elegant way to solve a problem could be a way that solves it more efficiently (faster) than others.

citrin_ru 6y ago
Depending on situation it can be part of #1 - make it work. If a GUI application instead of <200ms has many seconds response time it kind of work, but it depends. I would not use a mail client if it takes a few minutes to open an IMAP folder or a message. But I'm OK with waiting much longer when I'm compressing a multi gigabyte file. If a backend change increases resource usage and now you need 3x more servers (VMs e. t. c.) it kind of work, but can push the project out of the budget ...or it can be a killer feature which would be worth to spend money on.
Firadeoclus 6y ago
Mostly I'd agree. It could also fall under #5, as a trade-off between developer time and user time. And sometimes #1, if speed is an essential requirement.
908B64B197 6y ago
Yes. High performance code is a world of it's own. Readability and elegance is going to be pretty different in that particular domain anyways. But 95% of code doesn't need the absolute best performance anyways.

nvader 6y ago

I am partial to the formulation, "Make it correct, make it clear, make it concise, make it fast. In that order." - Wes Dyer

auslegung 6y ago
When I think of “make it work”, I think, “do any hackey thing you need to to get it to work”. Then in the next step, “make it right“, I refactor and clean up. It’s much like writing, where the advice is to write without censoring, then edit later. I think the idea is it’s always easier to edit something that exists, rather than write something correct the first time, or at least try to make it correct the first time. That being said, when I read your quote where it first says “make it correct”, I would skip the first step I mentioned above, which is a very important step. What are your thoughts?

bironran 6y ago

> Correct: ... Is it performant enough for this use case? I completely agree with that definition of correct. Code should be performant _enough_ for the use case. It shouldn't strive for the unachievable "infinite performance" or "endless scalability". It should do well now and in the next performance / growth cycle (usually measured in months to a low number of years unless you're in hyper growth). However I disagree with "Secure" being on a different level than "Correct". Or rather, the "release" line passes over the secure. I may not be happy with the structure of the code, but I will never knowingly release insecure code or allow such code to be released if I can help it. The impact of security issues to the bottom line is usually far greater (in both immediate and future terms) than the impact of any non-data-loss inducing functional issue. -- addendum --- Also I miss "being evolution ready" (future proofing). Sometimes you give up on some of the other aspects to make sure your code (and the data it governs) can be evolved should the need arise.