Laws of Software Engineering • Hacker News Board

Re: Laws of Software Engineering

#531

Post by sov » Wed, Apr 22, 2026, 9:43 PM UTC

davedx wrote: post #202

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…

"today, performance is mostly about architectural choices, and it has to be given consideration right from the start" This doesn't make sense. Why is performance (via architectural choices) more important today than then? You can build a snappy app today by using boring technology and following some sensible best practices. You have to work pretty hard to need PREMATURE OPTIMIZATION on a project -- note the premature…

"dont prematurely optimize" is talking about optimization SEPERATE from architecture (and how pre-mature optimization as Knuth describes gets in the way of correct architecture). nowadays, almost any optimization purely distinct from architecture is handled either by cpu arch/logic improvements, compiler/interpreter improvements, or buried in the overwhelming tide of cpu speedups, so TODAY these terms get conflated as architecture IS typically how we optimize.

Re: Laws of Software Engineering

#532

Post by konovalov-nk » Wed, Apr 22, 2026, 9:56 PM UTC

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…

Recently I stumbled upon this crazy thing: https://github.com/anomalyco/opencode/issues/9676#issuecomme...

`ripgrep` tool call on opencode added `--follow` override, which allowed to traverse symlinks. And you can imagine what happens when symlinks point to ancestors. My 9950x3D CPU had 100% load all the time until I did a bit of research and added config to forbid this on `rg` level.

So I'd refine it as "Premature optimization is the root of all evil. Blatant ignorance of it is even worse."

Re: Laws of Software Engineering

#533

Post by brendaninnis » Wed, Apr 22, 2026, 10:01 PM UTC

The Dunning-Kruger Effect card is so bad here. The effect is not that your perceived ability is higher the less skilled you are, but that the gap between your actual ability and perceived ability is larger the less skilled you are (and becomes negative when highly skilled). This is so commonly misstated this way that I think most people have this misunderstanding.

Also they used the graph for the Gartner Hype Cycle as the icon, not the Dunning-Kruger graph.

Re: Laws of Software Engineering

#534

Post by didgetmaster » Wed, Apr 22, 2026, 10:35 PM UTC

kitd wrote: post #485

didgetmaster wrote: post #358

Earlier quoted context omitted.

I once interviewed at Microsoft. The hiring manager asked me how I would go about programming a break point if I were writing a debugger. I started to explain how I would have to swap out an instruction to put an INT 3 in the code and then replace it when the breakpoint would hit. He stopped me an said he was just looking to see if I knew what an INT 3 was. He said few engineers he interviewed had any idea.

Did you get the job ... or were you overqualified?

I guess I was overqualified. Didn't get the job.

Re: Laws of Software Engineering

#535

Post by [deleted] » Thu, Apr 23, 2026, 3:41 AM UTC

wredcoll wrote: post #466

YZF wrote: post #464

Earlier quoted context omitted.

Before you write code you design (and/or architect) a system (formally or informally). There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.

[deleted]

Re: Laws of Software Engineering

#536

Post by YZF » Thu, Apr 23, 2026, 3:42 AM UTC

dimitrios1 wrote: post #515

YZF wrote: post #429

Earlier quoted context omitted.

This is true but doesn't help. Parent is talking about building software that is inherently non-performant due to abstractions or architecture with the wrong assumption that it can be optimized later if needed. The analogy is trying to convert a garbage truck into a race car. A race car is built as a race car. You don't start building a garbage truck and then optimize it on the race course. There are obvious principl…

Ha! -- Allow me to introduce you to the US Diesel Truckin Nationals! Here are some dump trucks drag racing https://www.youtube.com/watch?v=aqxpOPeImkw

lol. TIL. But they're not racing Formula 1.

Re: Laws of Software Engineering

#537

Post by YZF » Thu, Apr 23, 2026, 3:48 AM UTC

wredcoll wrote: post #466

YZF wrote: post #464

Earlier quoted context omitted.

Before you write code you design (and/or architect) a system (formally or informally). There's too little appreciation today for a well designed system. And the "premature optimization" line is often used to justify not thinking about things because, hey, that's premature. Just throw something together.

Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.

Getting feedback from users for a product is important as well. Those are somewhat orthogonal concepts. I'm not proposing analysis paralysis or no prototyping but I am saying there are some things that if you didn't consider in advance can become huge issues down the road. There are examples (e.g. Facebook or the Google crawler) where very successful products started with something not great and then were able to fix that later but I would argue most of the very successful products and platforms (software or not) have had some non-negligible thinking/planning upfront.

Re: Laws of Software Engineering

#538

Post by Kinrany » Thu, Apr 23, 2026, 8:53 AM UTC

heap_perms wrote: post #166

Kinrany wrote: post #136

SOLID being included immediately makes me have zero expectation of the list being curated by someone with good taste.

That's interesting, what makes you think that? Not long ago, I was working on my degree in Computer Science (Software Engineering), and we were heavily drilled on this principle. Even then, I found it amusing how all the professors were huge fanboys of SOLID. It was very dogmatic.

In modern terms, it's marketing slop. It is what ChatGPT could have created at the time if it was asked to select a bunch of "best practices" and form a punchy acronym out of them.

There's no system, it's five rules selected at random.

Worse, their usefulness varies from hopelessly vague through trivial to actively confusing.

Re: Laws of Software Engineering

#539

Post by switchbak » Thu, Apr 23, 2026, 2:18 PM UTC

gf000 wrote: post #480

switchbak wrote: post #291

Earlier quoted context omitted.

It's substantially worse on the JVM. One's intuition from C just fails when you have to think about references vs primitives, and the overhead of those (with or without compressed OOPs). I've met very few folks who understand the overheads involved, and how extreme the benefits can be from avoiding those.

In what way is it worse? The range of values they can contain is well-specified. And you have a frame with an operands stack where you should be able to store at least a 32-bit value. `double` would just fill 2 adjacent slots. And references are just pointers (possibly not using the whole of the value as an address, but as flags for e.g. the GC) pointing to objects, whose internal structure is implementation detail,…

I’m saying very few folks understand the cost tradeoffs of using references/objects versus using primitives directly. The difference in memory used for significant amounts of data is huge.

Not to mention indirection costs, but that’s a different issue.

Re: Laws of Software Engineering

#540

Post by biscuits1 » Thu, Apr 23, 2026, 5:05 PM UTC

voiceofunreason wrote: post #250

biscuits1 wrote: post #211

Today, I was presented with Claude's decision to include numerous goto statements in a new implementation. I thought deeply about their manual removal; years of software laws went against what I saw. But then, I realized it wouldn't matter anymore. Then I committed the code and let the second AI review it. It too had no problem with goto's. Claude's Law: The code that is written by the agent is the most correct way t…

Render therefore unto Caesar the things which are Caesar's; and unto Claude the things that are Claude's.

And so, it is written:

https://dev.to/solidi/claudes-law-1da7