Declining software quality

[mtbc]

I was chatting recently with somebody who shares my observations on the apparent decline of the quality of software and figured that I may as well capture the broad strokes of my thoughts here.

Certainly back in the 1980s, maybe also the 1990s, software often impressed me. I could easily figure out how to use it, how to get it to do what I wanted, and it was genuinely a surprise to discover a bug. These days I often find software to be difficult to get on with, trying to force me into specific workflows of what somebody thinks users ought to want to be able to do, and positively bug-ridden.

One thing I am curious about is to what extent this trend is quantitatively corroborated. Organizations like NASA put research money into assessing software quality. I wonder what they have found.

Another is, what's the cause? Is it that there are so many people now entering the software industry that their typical ability level is much lower? Is it the false economy of building one's software atop a whole stack of complex third-party libraries that are all too often both buggy and barely maintained? I suspect that those two are connected: that it may take a certain skill level to recognize a steaming pile of festering liability just as it takes a decent programmer to be able to recognize one in recruitment interviews. Or maybe they have to use the third-party cruft because they don't see how they can easily just build the part they need themselves and wouldn't recognize clean elegance even if it lived next door to them.

Or maybe it's a social change in what's acceptable: professional pride giving way to commercial expediency, a market failure of rewarding feature lists over reliability, etc. Perhaps I am a poor fit for the modern world in caring more about software being clear and correct rather than featureful.

I see so much software that feels to me like it should never have gotten through even permissive quality assurance: for instance, I perform some input action, clicking a button or whatever, and there is no immediate visual change to confirm that my act was noticed, then the action goes on to do something that is both surprising and difficult to reverse. Even from companies that are meant to be good at user interfaces I see horrors, like from Apple: visually identical indicators having diverse meanings and actions having no visible effect on the corresponding status display. This is such basic stuff but people do not get it correct any more and it makes me want to find some other technical industry in which quality still matters.

I am not against learning new things, I just find few of them worthwhile. New so often does not mean better. This has been true for a while: witness Java's failure to learn from Modula-3 in so many ways. There are some good developments, for example if I wanted PostScript now I expect I would be better off with Cairo. And, a big development for me in more recent years was Haskell: its casually convenient capacity for flexible abstraction means that when I need some piece of framework atop which to build my application, I can often easily roll it myself and it will generally turn out to be simple, correct and reusable. Haskell does also have some high-quality third-party libraries. But, it is not good for my employability to wall myself off in a niche, especially when living somewhere with a lower density of software jobs than I am used to. Things are not all bad: for instance, I would be happy to dust off my JavaScript given that browser support seems to become less of an awkward issue as time goes on and the new java.time library is an improvement over the previous date and calendar horror. But the new learning I do that feels pleasant tends to be of old technologies, like Erlang.

Comments

[aldabra]

I've been in businesses which wrote their own software, or used niche providers with high quality products. In both cases they did well for the first five or ten years, and then the maintenance overhead rose and the mainstream competition overtook on features or became industry standard, and in the end they had to back off to whatever was ahead in the market, because they or the small provider couldn't keep up even though the product met their needs better. It became cheaper to use software which cost more and was worse, because somebody else was doing the bugfixes and format changes and updates.

Also, I think there's invisible exponentially increased complexity because things have to maintain backwards compatibility. Office is running with two sets of menus now; the clicky-through ribbons at the top, and the keyboard shortcuts which match the previous drop-down menus. The number of file formats they support is proliferating (but no longer include .dbs, which our previous mapping software required). I suspect in 1985 there were people at Microsoft who understood the design, and the design decisions, and knew roughly how it worked. I bet there is nobody alive who understands the current versions.

(In a previous workplace I was assigned to maintaining 10,000 lines of C code; they handed me Kernighan & Ritchie and the obfuscated C archive on day 1 and told me to teach myself. Comments in the code were very sparse, and included "I bet you can't see why I did it like this!" It worked until it didn't, and by then they'd gone off the idea of writing their own.)

[mtbc]

Certainly it sounds like planning for updatability, even occasional reimplementation, is key. Maybe also a file format upgrader rather than eternal backward support.

The accumulated cruft issue I find partly comes from not implementing things in a clear, documented way and never getting around to doing so that eventually there's just an enormous pile of barely comprehensible code.

[aldabra]

Also, they make random changes to UI and functionality, and I think these are disproportionately annoying because you notice when things you use or like change for the worse much more than you notice when things change for the better (this may be partly because you have workarounds in place and don't notice, or because your workarounds stop working and you have to back off and see why). And then eventually they say obviously nobody is using 1998-style macros any more and turn them off and your software breaks. I don't *care* whether 2013 macros are objectively better; I don't want to have to spend time learning about them (and relearning about the obsolete ones so I can tell how to reimplement them).

I find increasingly that my brain is refusing to engage with things because it has spotted that three years later they will have changed again. VCRs, for example. I'm fairly sure I could still work the one we had when I was eighteen, but every time one breaks and we upgrade I engage with it less. LJ: I might have been vaguely interested in styles and themes in 2003, but they've changed it without warning more than once and now I just want it to stay still and inoffensive and legible (and ideally not in Russia).

So I'm not interested to the same extent as I was in whether things work pleasingly, because even if they do I expect them to change without warning and get worse.

[mtbc]

True: I find that especially anything that grows in popularity and gains a larger development team declines in quality and (for me) usability. I also now don't bother learning how to use all things, for example I really have not bothered trying to learn how to wrangle iOS.

Mind you, LibreOffice mostly doesn't yet irritate me.