Ask HN: Why is software quality always decreasing?

Entropy is a scientific concept as well as a measurable physical property that is most commonly associated with a state of disorder, randomness, or uncertainty

What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? :)

> And I agree that tests make refactoring easier.

They don't make it easier. They make it POSSIBLE.

> And so, what specific quality guarantees do good tests make?

Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database.

This is all very much basic IT stuff for long time, particularly nowadays when software needs to run not only in your basement but on every conservable device and number of different contexts!

No offense, but you seem new in this business, and your aggression doesn't help at all.

As software systems (like many systems) go from initial development (which may or may not have a solid vision and initially highly disciplined development approach) to long term maintenance, disorder creeps into the system. Often just as a matter of expedience, "Let me make this field public so this other module can modify it directly because I need it now, I'll come up with a proper interface later. Oh shit, three years later 100 modules are making use of that public field."

What tests do, in this case, is help to preserve order. They help to ensure that a more rigid and ordered structure for the code remains. Formal methods only take you so far because, outside of maybe coq and related languages, there is no direct connection between your formal method spec and the code that has been written, in contrast to tests (which can be derived from your formal spec, but usually manually). Of course, tests can only carry you so far, they also have to be maintained. If a test is removed because it's no longer relevant, is another test put in its place to verify the new system? Are tests disabled because they're only failing sporadically or because the bugs they represent are hard to fix and we don't know how to yet (or don't have the time)?

Gradually, a system starts to suffer from various problems of this sort, that's entropy. Maintaining quality is a constant struggle against various forces (convenience, loss of institutional knowledge, time pressure, etc.). Tests are one way (and a critical way) to help balance against those forces.

EDIT: Other formal methods that work with real systems would be in Ada/SPARK, ATS, or Frama-C and I'm surprised I didn't mention them above. However, at least with SPARK, it narrows the scope of what you can do with the system and prove properties about it. That scope is always increasing, but is still a subset of what Ada itself can do. That's not all bad, but this means you can only consistently prove (in a formal sense) properties of subsets of a larger system and will likely be unable to prove (in an automatic fashion at least) a significant number of properties of those same larger systems.

Having done a lot of work on the kernel, I think you’d be surprised at the relatively low quality of a lot of kernel drivers.

The core code is generally quite good, but it’s not true that the kernel is full of pristine code.

I’ve worked at multiple companies where code quality standards exceeded a lot of the weirder stuff I’ve seen (and often fixed) in kernel driver code.

For me, this is a game of perceptions where crappy software becomes popular and profit motive makes it risky to attempt iterations. No executive working at Microsoft is interested in the liability that would come with a win32 rewrite of Teams, even if the UX would triple in quality overnight.

If anything, the quality of most software should be dramatically better than ever before, especially when you factor in the relevant tools & ecosystems.