One that is missing is Ousterhout’s rule for decomposing complexity: complexity(system) = sum(complexity(component) * time_spent_working_in(component) for component in system). The rule suggests that encapsulating complexity (e.g., in stable libraries that you never have to revisit) is equivalent to eliminating that complexity.
Laws of Software Engineering
191–200 of 554 posts
Re: Laws of Software Engineering
#192This one belongs to history books, not to the list of contemporary best practices.
Re: Laws of Software Engineering
#193Remember 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
Sort of like a real code of law.
Re: Laws of Software Engineering
#194On my laptop I have a yin-yang with DRY and YAGNI replacing the dots.
Re: Laws of Software Engineering
#195> Premature optimization is the root of all evil. There are few principle of software engineering that I hate more than this one, though SOLID is close. It is important to understand that it is from a 1974 paper, computing was very different back then, and so was the idea of optimization. Back then, optimizing meant writing assembly code and counting cycles. It is still done today in very specific applications, but t…
Decades in, this is the worst of all of them. Misused by laziness or malice, and nowhere near specific enough.
The graveyard of companies boxed in by past poor decisions is sprawling. And the people that made those early poor decisions bounce around field talking about their "successful track record" of globally poor and locally good architectural decisions that others have had to clean up.
It touches on a real problem, though, but it should be stricken form the record and replaced with a much better principle. "Design to the problem you have today and the problems you have in 6 months if you succeed. Don't design to the problems you'll have have next year if it means you won't succeed in 6 months" doesn't roll off the tongue.
Re: Laws of Software Engineering
#196Earlier quoted context omitted.
We have HIPAA in the US for health care data. There have been no disastrous consequences to holding people and organizations responsible for breaches.
Sure, and in cases of negligence this is fine. The law even explicitly scales the punishment based on perceived negligence and almost always is only prosecuted in cases where the standards expectations aren't followed. Ex - MMG for 2026 was prosecuted because: - They failed to notify in response to a breach. - They failed to complete proper risk analysis as required by HIPAA They paid 10k in fines. It wasn't just "Th…
Re: Laws of Software Engineering
#197Earlier quoted context omitted.
> It must not be both a floor polish and a dessert topping. I worked as a janitor for four years near a restaurant, so I know a little bit about floor polishing and dessert toppings. This law might be a little less universal than you think. There are plenty of people who would happily try out floor polish as a dessert topping if they're told it'll get them high.
It’s a reference to a very old SNL sketch called “shimmer”. https://www.youtube.com/shorts/03lLPUYkpYM It probably won’t be up very long but it’s a classic.
I’m still waiting for the moment in the ice cream shop when I can ask them, “sugar or plain?” https://mediaburn.org/videos/sugar-or-plain/
Re: Laws of Software Engineering
#198Earlier quoted context omitted.
> It must not be both a floor polish and a dessert topping. I worked as a janitor for four years near a restaurant, so I know a little bit about floor polishing and dessert toppings. This law might be a little less universal than you think. There are plenty of people who would happily try out floor polish as a dessert topping if they're told it'll get them high.
It’s a reference to a very old SNL sketch called “shimmer”. https://www.youtube.com/shorts/03lLPUYkpYM It probably won’t be up very long but it’s a classic.
Re: Laws of Software Engineering
#199> Premature optimization is the root of all evil. There are few principle of software engineering that I hate more than this one, though SOLID is close. It is important to understand that it is from a 1974 paper, computing was very different back then, and so was the idea of optimization. Back then, optimizing meant writing assembly code and counting cycles. It is still done today in very specific applications, but t…