7 ms·

Remember that these "laws" contain so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you wan

Remember that these "laws" contain so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. The hard part is knowing which law break when, and why

ghm2180 6mo ago
This is doubly true in Machine Learning Engineering. Knowing what methods to avoid is just as important to know what might work well and why. Importantly a bunch of Data Science techniques — and I use data science in the sense of making critical team/org decisions — is also as important for which you should understand a bit of statistics not only data driven ML.
- Silamoth 6mo ago
  Statistics is absolutely fundamental to data science. But I’m not sure this relates to the above idea of “laws” being internally contradictory?
AussieWog93 6mo ago
DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.
- pydry 6mo ago
  DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when to apply it ("use it when it makes sense") and thats not really much better than being a DRY fundamentalist.
  - layer8 6mo ago
    DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.
    - xnorswap 6mo ago
      I like this a lot more, because it captures whether two things are necessarily the same or just happen to be currently the same. A common "failure" of DRY is coupling together two things that only happened to bear similarity while they were both new, and then being unable to pick them apart properly later.
      - CodesInChaos 6mo ago
        > then being unable to pick them apart properly later. Which is often caused by the "midlayer mistake" https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
    - mcv 6mo ago
      That's how I understood it. If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY.
      - mjr00 6mo ago
        > If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY. The tricky part is that sometimes "a new thing" is really "four new things" disguised as one. A database table is a great example because it's a failure mode I've seen many times. A developer has to do it once and they have to add what they perceive as the same thing four times: the database table itself, the internal DB->code translation e.g. ORM mapping, the API definition, and maybe a CRUD UI widget. The developer thinks, "oh, this isn't DRY" and looks to tools like Alembic and PostGREST or Postgraphile to handle this end-to-end; now you only need to write to one place when adding a database table, great! It works great at first, then more complex requirements come down: the database gets some virtual generated columns which shouldn't be exposed in code, the API shouldn't return certain fields, the UI needs to work off denormalized views. Suddenly what appeared to be the same thing four times is now four different things, except there's a framework in place which treats these four things as one, and the challenge is now decoupling them. Thankfully most good modern frameworks have escape valves for when your requirements get more complicated, but a lot of older ones[0] really locked you in and it became a nightmare to deal with. [0] really old versions of Entity Framework being the best/worst example.
- busfahrer 6mo ago
  I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates
  - whattheheckheck 6mo 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 6mo 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 6mo ago
        And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
        shermantanktop 6mo 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 6mo 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.
- iwontberude 6mo ago
  Why do the have to be so smart but so annoying at the same time?
- zahlman 6mo ago
  I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?
  - dasil003 6mo ago
    Buy me a beer and I can tell you some very poignant stories. The best ones are where there is a legitimate abstraction that could be great, assuming A) everyone who had to interact with the abstraction had the expertise to use it, B) the details of the product requirements conformed to the high level technical vision, now and forever, and C) migrating from the current state to the new system could be done in a bounded amount of time. My view is over-engineering comes from the innate desire of engineers to understand and master complexity. But all software is a liability, every decision a tradeoff that prunes future possibilities. So really you want to make things as simple as possible to solve the problem at hand as that will give you more optionality on how to evolve later.
  - caminante 6mo ago
    IMHO, it comes down to awareness/probability about the need to future proof or add defensive behavior. The spectrum is [YAGNI ---- DRY] A little less abstract: designing a UX comes to mind. It's one thing to make something workable for you, but to make it for others is way harder.
  - mosburger 6mo ago
    I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic. The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
    - physicles 6mo ago
- aworks 6mo ago
  I worked for a company that also had hardware engineers writing RTL. Our software architect spent years helping that team reuse/automate/modularize their code. At a mininum, it's still just text files with syntax, despite rather different semantics.
- ericmcer 6mo ago
  DRY and KISS were right next to each other which I thought was funny.
jimmypk 6mo ago
[flagged]
- throwaway173738 6mo ago
  I look at Postel’s law more as advice on how to parse input. At some point you’re going to have to upgrade a client or a server to add a new field. If you’ve been strict, then you’ve created a big coordination problem, because the new field is a breaking change. But if you’re liberal, then your systems ignore components of the input that they don’t recognize. And that lets you avoid a fully coordinated update.
  - ragnese 6mo ago
    Yes, what Postel's Law is about. That's the whole point of contrasting it with Hyrum's Law, no? Hyrum's Law is pointing out that sometimes the new field is a breaking change in the liberal scenario as well, because if you used to just ignore the field before and now you don't, your client that was including it before will see a change in behavior now. At least by being strict, (not accepting empty arrays, extra fields, empty strings, incorrect types that can be coerced, etc), you know that expanding the domain of valid inputs won't conflict with some unexpected-but-previously-papered-over stuff that current clients are sending.
  - deleted 6mo ago
    [deleted]
- zahlman 6mo ago
  I've always thought of Hyrum's Law more as a Murphy-style warning than as actionable advice.
  - dmoy 6mo ago
    Yea hyrum's law is like an observation of what happens when you personally try to make 200,000+ distinct commits to google3 to fix things that are broken (as hyrum did, mind you this is before LLMs), and people come climbing out of the woodwork to yell at you with fistfuls of xkcd/1172
blandflakes 6mo ago
This was also true of Amazon's Leadership Principles. They are pretty reasonable guidelines, but in a debate, it really came down to which one you could most reasonably weaponize in favor of your argument, even to the detriment of several others. Which maybe is also fine, I dunno :)
- rustyhancock 6mo ago
  It's because they are heurists intended to be applied by knowledgeable and experienced humans. It can be quite hard to explain when a student asks why you did something a particular way. The truthful answer is that it felt like the right way to go about it. With some thought you can explain it partly - really justify the decision subconsciously made. If they're asking about a conscious decision that's rarely much more helpful that you having to say that's what the regulations, or guidelines say. Where they really learn is seeing those edge cases and gray areas
rapnie 6mo ago
I like alternatives to formal IT lawfare, like CUPID [0] properties for Joyful coding by Dan North, as alternative to SOLID principles. [0] https://cupid.dev/ https://cupid.dev/
diehunde 6mo ago
I guess that's why confirmation bias is also listed?
ChrisMarshallNY 6mo ago
Great point. Sort of like a real code of law.
jolt42 6mo ago
I'll propose this as the only unbreakable law: "everything in moderation", which I feel implies any law is breakable, which now this is sounding like the barber's paradox. What else does anyone propose as unbreakable?
- zdc1 6mo ago
  Counterpoint: "everything in moderation, including moderation"
- alok-g 6mo ago
  >> everything in moderation Saying this is like saying 'pick the optimum point' without saying anything about how to find the optimum point. This cannot be a law, it is the definition of optimum. Note that optimum point need not be somewhere in the middle or 'inside', like a maxima. The optimum point could very well be on an extreme of the domain (input variables space).
davedx 6mo ago
As a very senior SWE with a decent amount of eng decision making responsibility these days I still find I get so much mileage out of KISS and YAGNI that I never really think about any other laws. So much SWE is overengineering. Just like this website to be honest. You don't get away with all that bullshit in other eng professions where your BoM and labour costs are material.
- ryandrake 6mo ago
  I always thought it would be great if every line of software (or, chose some other unit of complexity) added to the unit cost of creating each copy. Like every bolt or gasket adds a few cents the the BOM of a piece of hardware. That fictional world would have simple, fast, and higher quality software programs.
ericmcer 6mo ago
Most of them felt contradictory and kind of antiquated. Reading through the list mostly made me feel sad. You can't help but interpret these through the modern lens of AI assisted coding. Then you wonder if learning and following (some) of these for the last 20 years is going to make you a janitor for a bunch of AI slop, or force you into a coding style where these rules are meaningless, or make you entirely irrelevant.
mday27 6mo ago
Seems to me like there's also a divide between observational laws (e.g. Hyrum's Law just says "this seems to be true") and prescriptive laws (e.g. Knuth's Law, which is really a statement about how you ought to behave)
httpz 6mo ago
That's why we call it software engineering, not software science.
heresie-dabord 6mo ago
> these "laws" contain so many internal contradictions Also notice how many of the so-called _software laws_ are actually statements about human behaviour and people-problems. Confirmation bias, Dunning-Kruger Effect, Sunk-Cost Fallacy, Ringlemann Effect, Price's Law, Putt's Law, Conway's Law, Brook's Law, Peter Principle, Hanlon's Razor, Amara's Law... Of the 59 "laws", only a small number are guiding principles specifically about planning and software. Human behaviour is hard to change -- the same dysfunction can be seen everywhere. As a fundamental principle, you need to use the right/best tool for the job; you will know when you are using the wrong tool/solution because you'll spend a significant amount of time trying to correct/mask the unwanted consequences. And if you enter a shop where many tools are wrong... consider going to work in a different shop.
xnx 6mo ago
> so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. More like the Bible of Software Engineering then

ghm2180 6mo ago

This is doubly true in Machine Learning Engineering. Knowing what methods to avoid is just as important to know what might work well and why. Importantly a bunch of Data Science techniques — and I use data science in the sense of making critical team/org decisions — is also as important for which you should understand a bit of statistics not only data driven ML.

Silamoth 6mo ago
Statistics is absolutely fundamental to data science. But I’m not sure this relates to the above idea of “laws” being internally contradictory?

AussieWog93 6mo ago

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

pydry 6mo ago
DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when to apply it ("use it when it makes sense") and thats not really much better than being a DRY fundamentalist.
- layer8 6mo ago
  DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.
  - xnorswap 6mo ago
    I like this a lot more, because it captures whether two things are necessarily the same or just happen to be currently the same. A common "failure" of DRY is coupling together two things that only happened to bear similarity while they were both new, and then being unable to pick them apart properly later.
    - CodesInChaos 6mo ago
      > then being unable to pick them apart properly later. Which is often caused by the "midlayer mistake" https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
  - mcv 6mo ago
    That's how I understood it. If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY.
    - mjr00 6mo ago
      > If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY. The tricky part is that sometimes "a new thing" is really "four new things" disguised as one. A database table is a great example because it's a failure mode I've seen many times. A developer has to do it once and they have to add what they perceive as the same thing four times: the database table itself, the internal DB->code translation e.g. ORM mapping, the API definition, and maybe a CRUD UI widget. The developer thinks, "oh, this isn't DRY" and looks to tools like Alembic and PostGREST or Postgraphile to handle this end-to-end; now you only need to write to one place when adding a database table, great! It works great at first, then more complex requirements come down: the database gets some virtual generated columns which shouldn't be exposed in code, the API shouldn't return certain fields, the UI needs to work off denormalized views. Suddenly what appeared to be the same thing four times is now four different things, except there's a framework in place which treats these four things as one, and the challenge is now decoupling them. Thankfully most good modern frameworks have escape valves for when your requirements get more complicated, but a lot of older ones[0] really locked you in and it became a nightmare to deal with. [0] really old versions of Entity Framework being the best/worst example.
busfahrer 6mo ago
I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates
- whattheheckheck 6mo 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 6mo 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 6mo ago
      And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
      - shermantanktop 6mo 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 6mo 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.
iwontberude 6mo ago
Why do the have to be so smart but so annoying at the same time?
zahlman 6mo ago
I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?
- dasil003 6mo ago
  Buy me a beer and I can tell you some very poignant stories. The best ones are where there is a legitimate abstraction that could be great, assuming A) everyone who had to interact with the abstraction had the expertise to use it, B) the details of the product requirements conformed to the high level technical vision, now and forever, and C) migrating from the current state to the new system could be done in a bounded amount of time. My view is over-engineering comes from the innate desire of engineers to understand and master complexity. But all software is a liability, every decision a tradeoff that prunes future possibilities. So really you want to make things as simple as possible to solve the problem at hand as that will give you more optionality on how to evolve later.
- caminante 6mo ago
  IMHO, it comes down to awareness/probability about the need to future proof or add defensive behavior. The spectrum is [YAGNI ---- DRY] A little less abstract: designing a UX comes to mind. It's one thing to make something workable for you, but to make it for others is way harder.
- mosburger 6mo ago
  I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic. The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
  - physicles 6mo ago
aworks 6mo ago
I worked for a company that also had hardware engineers writing RTL. Our software architect spent years helping that team reuse/automate/modularize their code. At a mininum, it's still just text files with syntax, despite rather different semantics.
ericmcer 6mo ago
DRY and KISS were right next to each other which I thought was funny.

jimmypk 6mo ago

[flagged]

throwaway173738 6mo ago
I look at Postel’s law more as advice on how to parse input. At some point you’re going to have to upgrade a client or a server to add a new field. If you’ve been strict, then you’ve created a big coordination problem, because the new field is a breaking change. But if you’re liberal, then your systems ignore components of the input that they don’t recognize. And that lets you avoid a fully coordinated update.
- ragnese 6mo ago
  Yes, what Postel's Law is about. That's the whole point of contrasting it with Hyrum's Law, no? Hyrum's Law is pointing out that sometimes the new field is a breaking change in the liberal scenario as well, because if you used to just ignore the field before and now you don't, your client that was including it before will see a change in behavior now. At least by being strict, (not accepting empty arrays, extra fields, empty strings, incorrect types that can be coerced, etc), you know that expanding the domain of valid inputs won't conflict with some unexpected-but-previously-papered-over stuff that current clients are sending.
- deleted 6mo ago
  [deleted]
zahlman 6mo ago
I've always thought of Hyrum's Law more as a Murphy-style warning than as actionable advice.
- dmoy 6mo ago
  Yea hyrum's law is like an observation of what happens when you personally try to make 200,000+ distinct commits to google3 to fix things that are broken (as hyrum did, mind you this is before LLMs), and people come climbing out of the woodwork to yell at you with fistfuls of xkcd/1172

blandflakes 6mo ago

This was also true of Amazon's Leadership Principles. They are pretty reasonable guidelines, but in a debate, it really came down to which one you could most reasonably weaponize in favor of your argument, even to the detriment of several others. Which maybe is also fine, I dunno :)

rustyhancock 6mo ago
It's because they are heurists intended to be applied by knowledgeable and experienced humans. It can be quite hard to explain when a student asks why you did something a particular way. The truthful answer is that it felt like the right way to go about it. With some thought you can explain it partly - really justify the decision subconsciously made. If they're asking about a conscious decision that's rarely much more helpful that you having to say that's what the regulations, or guidelines say. Where they really learn is seeing those edge cases and gray areas

rapnie 6mo ago

I like alternatives to formal IT lawfare, like CUPID [0] properties for Joyful coding by Dan North, as alternative to SOLID principles. [0] https://cupid.dev/ https://cupid.dev/

diehunde 6mo ago

I guess that's why confirmation bias is also listed?

ChrisMarshallNY 6mo ago

Great point. Sort of like a real code of law.

jolt42 6mo ago

I'll propose this as the only unbreakable law: "everything in moderation", which I feel implies any law is breakable, which now this is sounding like the barber's paradox. What else does anyone propose as unbreakable?

zdc1 6mo ago
Counterpoint: "everything in moderation, including moderation"
alok-g 6mo ago
>> everything in moderation Saying this is like saying 'pick the optimum point' without saying anything about how to find the optimum point. This cannot be a law, it is the definition of optimum. Note that optimum point need not be somewhere in the middle or 'inside', like a maxima. The optimum point could very well be on an extreme of the domain (input variables space).

davedx 6mo ago

As a very senior SWE with a decent amount of eng decision making responsibility these days I still find I get so much mileage out of KISS and YAGNI that I never really think about any other laws. So much SWE is overengineering. Just like this website to be honest. You don't get away with all that bullshit in other eng professions where your BoM and labour costs are material.

ryandrake 6mo ago
I always thought it would be great if every line of software (or, chose some other unit of complexity) added to the unit cost of creating each copy. Like every bolt or gasket adds a few cents the the BOM of a piece of hardware. That fictional world would have simple, fast, and higher quality software programs.

ericmcer 6mo ago

Most of them felt contradictory and kind of antiquated. Reading through the list mostly made me feel sad. You can't help but interpret these through the modern lens of AI assisted coding. Then you wonder if learning and following (some) of these for the last 20 years is going to make you a janitor for a bunch of AI slop, or force you into a coding style where these rules are meaningless, or make you entirely irrelevant.

mday27 6mo ago

Seems to me like there's also a divide between observational laws (e.g. Hyrum's Law just says "this seems to be true") and prescriptive laws (e.g. Knuth's Law, which is really a statement about how you ought to behave)

httpz 6mo ago

That's why we call it software engineering, not software science.

heresie-dabord 6mo ago

> these "laws" contain so many internal contradictions Also notice how many of the so-called _software laws_ are actually statements about human behaviour and people-problems. Confirmation bias, Dunning-Kruger Effect, Sunk-Cost Fallacy, Ringlemann Effect, Price's Law, Putt's Law, Conway's Law, Brook's Law, Peter Principle, Hanlon's Razor, Amara's Law... Of the 59 "laws", only a small number are guiding principles specifically about planning and software. Human behaviour is hard to change -- the same dysfunction can be seen everywhere. As a fundamental principle, you need to use the right/best tool for the job; you will know when you are using the wrong tool/solution because you'll spend a significant amount of time trying to correct/mask the unwanted consequences. And if you enter a shop where many tools are wrong... consider going to work in a different shop.

xnx 6mo ago

> so many internal contradictions that when they're all listed out like this, you can just pick one that justifies what you want to justify. More like the Bible of Software Engineering then