6 ms·

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

mcv 5mo ago
I once heard of a counter-principle called WET: Write Everything Twice.
whattheheckheck 5mo ago
Why 3? What is this baseball? Take the 5 Rings approach. The purpose of the blade is to cut down your opponent. The purpose of software is to provide value to the customer. It's the only thing that matters. You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment
- ta20240528 5mo ago
  "The purpose of software is to provide value to the customer." Partially correct. The purpose of your software to its owners is also to provide future value to customers competitively. What we have learnt is that software needs to be engineered: designed and structured.
  - nradov 5mo ago
    And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
    - shermantanktop 5mo ago
      If you get lucky doing that you might regret it. Especially with non-technical management. Making software is a back-of-house function, in restaurant terms. Nobody out there sees it happen, nobody knows what good looks like, but when a kitchen goes badly wrong, the restaurant eventually closes.
    - galbar 5mo ago
      These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice. This is a very costly way of developing software.
      - nradov 5mo ago
        It's easy to say that organizations should do it right the first time, in terms of applying proper engineering practices. But they often didn't have the time, capital, and skillset to do that. Not ideal, but that's often how things work in the real world and it will never change.
        datadrivenangel 5mo ago
        Organizations should do it not catastrophically wrongly, especially once a core design / concept is mostly solidified. Putting a little time into reliability and guardrails prevents a huge amount of downside. I've been at organizations that don't think engineers should write tests because it takes too much time and slows them down...
    - lamasery 5mo ago
      Plenty of businesses or products within businesses stagnate and fail because their software got too expensive to maintain and extend. Not infrequently, this happens before it even sees a public release. Any business that can't draw startup-type levels of investment to throw effectively infinite amounts of Other People's Money at those kinds of problems, risks that end if they allow their software to get too messed-up. The "who gives a shit, we'll just rewrite it at 100x the cost" approach to quality is very particular to the software startup business model, and doesn't work elsewhere.
- marcosdumay 5mo ago
  Why baseball? You don't use the number 3 in any other context? If you write a lot of code, the odds of something repeating in another place just by coincidence are quite large. But the odds of the specific code that repeated once repeating again are almost none. That's a basic rule from probability that appears in all kinds of contexts. Anyway, both DRY and WET assume the developers are some kind ignorant automaton that can't ever know the goal of their code. You should know if things are repeating by coincidence or not.
- TheGRS 5mo ago
  One is one. Two is a coincidence. And three is a trend. That's my personal head canon.
  - D-Coder 5mo ago
    "Once is happenstance. Twice is coincidence. The third time it's enemy action." — Auric Goldfinger
- jimbokun 5mo ago
  Rule of 3 will greatly benefit the customer over time as it lessens the probability of bugs and makes adding new features faster.
michaelcampbell 5mo ago
The "Rule of 3" is a pretty well known rule of thumb; I suspect Carmack would admit it predates him by a fair bit.
jimbokun 5mo ago
Another law for the list!

mcv 5mo ago

I once heard of a counter-principle called WET: Write Everything Twice.

whattheheckheck 5mo ago

Why 3? What is this baseball? Take the 5 Rings approach. The purpose of the blade is to cut down your opponent. The purpose of software is to provide value to the customer. It's the only thing that matters. You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment

ta20240528 5mo ago
"The purpose of software is to provide value to the customer." Partially correct. The purpose of your software to its owners is also to provide future value to customers competitively. What we have learnt is that software needs to be engineered: designed and structured.
- nradov 5mo ago
  And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
  - shermantanktop 5mo ago
    If you get lucky doing that you might regret it. Especially with non-technical management. Making software is a back-of-house function, in restaurant terms. Nobody out there sees it happen, nobody knows what good looks like, but when a kitchen goes badly wrong, the restaurant eventually closes.
  - galbar 5mo ago
    These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice. This is a very costly way of developing software.
    - nradov 5mo ago
      It's easy to say that organizations should do it right the first time, in terms of applying proper engineering practices. But they often didn't have the time, capital, and skillset to do that. Not ideal, but that's often how things work in the real world and it will never change.
      - datadrivenangel 5mo ago
        Organizations should do it not catastrophically wrongly, especially once a core design / concept is mostly solidified. Putting a little time into reliability and guardrails prevents a huge amount of downside. I've been at organizations that don't think engineers should write tests because it takes too much time and slows them down...
  - lamasery 5mo ago
    Plenty of businesses or products within businesses stagnate and fail because their software got too expensive to maintain and extend. Not infrequently, this happens before it even sees a public release. Any business that can't draw startup-type levels of investment to throw effectively infinite amounts of Other People's Money at those kinds of problems, risks that end if they allow their software to get too messed-up. The "who gives a shit, we'll just rewrite it at 100x the cost" approach to quality is very particular to the software startup business model, and doesn't work elsewhere.
marcosdumay 5mo ago
Why baseball? You don't use the number 3 in any other context? If you write a lot of code, the odds of something repeating in another place just by coincidence are quite large. But the odds of the specific code that repeated once repeating again are almost none. That's a basic rule from probability that appears in all kinds of contexts. Anyway, both DRY and WET assume the developers are some kind ignorant automaton that can't ever know the goal of their code. You should know if things are repeating by coincidence or not.
TheGRS 5mo ago
One is one. Two is a coincidence. And three is a trend. That's my personal head canon.
- D-Coder 5mo ago
  "Once is happenstance. Twice is coincidence. The third time it's enemy action." — Auric Goldfinger
jimbokun 5mo ago
Rule of 3 will greatly benefit the customer over time as it lessens the probability of bugs and makes adding new features faster.

michaelcampbell 5mo ago

The "Rule of 3" is a pretty well known rule of thumb; I suspect Carmack would admit it predates him by a fair bit.

jimbokun 5mo ago

Another law for the list!