Laws of Software Engineering

Post by nazgul17 » Tue, Apr 21, 2026, 1:43 PM UTC

dgb23 wrote: post #78

I like this collection. It's nicely presented and at least at a glance it adds some useful context to each item. While browsing it, I of course found one that I disagree with: Testing Pyramid: https://lawsofsoftwareengineering.com/laws/testing-pyramid/ I think this is backwards. Another commenter WillAdams has mentioned A Philosophy of Software Design (which should really be called A Set of Heuristics for Software De…

Post by milanm081 » Tue, Apr 21, 2026, 1:44 PM UTC

bakkerinho wrote: post #70

> This site was paused as it reached its usage limits. Please contact the site owner for more information. Law 0: Fix infra.

Post by Silamoth » Tue, Apr 21, 2026, 1:47 PM UTC

layer8 wrote: post #32

pydry wrote: post #29

Earlier quoted context omitted.

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 t…

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.

Post by Silamoth » Tue, Apr 21, 2026, 1:48 PM UTC

ghm2180 wrote: post #17

conartist6 wrote: post #13

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

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.

Post by Silamoth » Tue, Apr 21, 2026, 1:54 PM UTC

dataviz1000 wrote: post #5

I did not see Boyd’s Law of Iteration [0] "In analyzing complexity, fast iteration almost always produces better results than in-depth analysis." Boyd invented the OODA loop. [0] https://blog.codinghorror.com/boyds-law-of-iteration/