Laws of Software Engineering

Post by nashashmi » Tue, Apr 21, 2026, 3:07 PM UTC

austin-cheney wrote: post #131

My own personal law is: When it comes to frameworks (any framework) any jargon not explicitly pointing to numbers always eventually reduces down to some highly personalized interpretation of easy. It is more impactful than it sounds because it implicitly points to the distinction of ultimate goal: the selfish developer or the product they are developing. It is also important to point out that before software framewor…

Post by lenerdenator » Tue, Apr 21, 2026, 3:08 PM UTC

Post by dzjkb » Tue, Apr 21, 2026, 3:12 PM UTC

ghosty141 wrote: post #167

GuB-42 wrote: 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…

What's the problem with SOLID? It's very very rare that I see a case where going against SOLID leads to better design.

Post by inetknght » Tue, Apr 21, 2026, 3:14 PM UTC

js8 wrote: post #139

inetknght wrote: post #80

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.

I thought that you were about to write: "as a janitor in a restaurant, the dessert topping is sometimes used as a floor polish".

Post by msla » Tue, Apr 21, 2026, 3:15 PM UTC

iamflimflam1 wrote: post #151

austin-cheney wrote: post #146

Earlier quoted context omitted.

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its nece…

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"