This made me immediately think of "The bug count also rises" http://www.snider.com/jeff/hemingway.html and of course Bryan Cantrills reading of it: https://youtu.be/4PaWFYm0kEw?t=1243

Since IIRC bug count is roughly proportional to source code line count, this implies the aggregate complexity of software doubles too. That might sound foreign, but if you think duplicated effort and accidental complexity rather than problem domain complexity it wouldn't surprise me if it was close to true.

Points to the value of sticking close to the problem domain.

I heard error count is proportional to LoC + # of developers involved in writing it. So as well as the accidental complexity from LoC, the more people touch a code base, the greater the chance of broken communication and misunderstandings. Ie bugs.

I suspect lines of code and number of developers are strongly enough correlated that it's hard to get any additional predictive power from the latter!

I think that's true when the source is first written. But # of devs only ever goes up during maintenance lifecycle, while loc may not change much.

Maybe. In my experience it's common for developers who were not part of the original effort to maintain by addition, because they are worried changing the existing code might break stuff. So with increased maintainer count the code size grows too.

I suspect the same holds true for hardware bugs in silicon, given the increasing complexity of CPUs. ;)

Maybe I'm naive but i think hardware cannot afford such condition. Even the name is a hint, software was termed so because it was easier to modify, allowing more errors to get in because you can fix it later at a lower cost.

Reading errata for Intel/AMD processors would be an eye opening experience then.

There are so many bugs in features you never heard of, just like software. It is inevitable given the complexity.

I'm sure there are tons of bugs, I was told a few stories by people in aerospace industry. But I think they cannot survive if they don't keep the number ultra low, because they can't fix it (well except microcode level).

They can't fix it, but compiler teams can.

It's a testament to those unsung heroes that most high-level language users can remain blissfully unaware of how much is automatically fixed by compilers in their emitted instructions.

Reminds me of the classic aerospace joke.

Q: In the age of Pentium, how do you pronounce IEEE-754? -- A: AAAAAAIIIIIIEEEEEEEEEE!

Reading errata for just the various STM32 microcontrollers was enough to dissuade me of the notion that hardware is infallible!

My personal favourite is from STM32F427:

"When PA12 is used as GPIO or alternate function in input or output mode, the data read from flash memory (bank2, upper 1MB) might be corrupted."

I can't even imagine the head scratching one might go through if hit by this, particularly late in development process (when the firmware becomes larger than 1MB).

Would fabrication failure be considered a bug? Isn't the rate kinda up there for chips that don't make it out of the factory? Not to mention on arrival there's a failure rate.

But also, I don't know too much about this, but when Linus tech tips did a tour of a chip fabrication plant, I remember learning that apparently the high end chips are chips where all the little bits inside all work, and if they detect like, busted wee transistors or whatever, they can just use that chip as a lower power processor. If that's the case that's like... Kinda a bug, but they just "code around it," right?

I'd say defect, not bug.

Yes, because those HW bugs are at the origin, SW bugs.

I heard that the last processor where they still used VLSI by hand was DECs ALPHA. Now everything comes from HDL synthesis so bugs are common.

Establishing an equivalent law for firmware would be interesting too.

Wirth's law :)

I love that!

Thanks for sharing it.