Live data from Hacker News

Laws of Software Engineering

lawsofsoftwareengineering.com

191–200 of 554 posts

Re: Laws of Software Engineering

#191
post #7

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.

Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.

Re: Laws of Software Engineering

#193

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

Great point.

Sort of like a real code of law.

Re: Laws of Software Engineering

#195
post #138

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

"Premature optimization is the root of all evil"

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

#196

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

Buildings don't just fall over, and security breaches don't just happen. These things happen when people fuck up. In the architecture world we hold individuals responsible for not fucking up--not the architect, but instead the licensed engineer who signs and seals the structural aspects of a plan. In the software world we do not.

Re: Laws of Software Engineering

#197

Earlier 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.

Of course for maximum confusion, there’s Gen X me, making this reference to my Gen Alpha kids who have absolutely no idea what I’m talking about.

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

#198

Earlier 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.

ah, I thought it was an Ubik reference!

Re: Laws of Software Engineering

#199
post #138

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

It's a very interesting topic. Even when designing a system, how to modularize, it's healthy to wait until the whole context is in sight. It's a bit of a black art, too early or too late you pay some price.
Post reply on HN