[jandrewrogers]

Software quality has been increasing for as long as I've been in the business. However, the complexity, scale, and defect surface of software has been increasing at least as quickly. We've invested the systemic gains in quality to expand the capabilities of what software can reasonably do instead of polishing the software we wrote 20+ years ago.

This was the right choice in most cases. The software from a few decades ago was inferior in almost every way to the software we have now for solving the problems we need to solve today. Most software does not live long enough to be "high quality", or it lives so long that its original design assumptions become obsolete and therefore less useful.

[timhrothgar]

I tend to agree when considering _new_ projects. A new project begins with a larger ecosystem of knowledgeable and experienced software professionals. This would include people tangent to software development (project managers, designers, executives, etc). I suppose the intent for asking the question was really something like, "how could or should one institutionalize quality improvement?" Maybe that starts with 1) ensuring that the business actually grows, 2) ensuring that the software actually works, and 3) ensuring that some flexibility is baked into management of software as an asset... or something along those lines.

[tharkun__]

I find this curious. I guess I don't really want to refute or validate your point too much either way and just want to share an anecdote to make people think.

I started out my career working for a large company (~10.000 employees in my actual company and the entire corp had >100.000 employees even back then).

I would probably agree that what you say is true for most software. Now why I find this curious is because the piece of software I was working on I think exhibited many if not all of those symptoms. It was old (about 15 years at the time, which by now is about 15 years ago and I'm pretty sure they still use a lot of that even though I have no way to check). So by now 30 years. It was archaic in many ways even back then. For ** sake, they were using CVS, they fixed stuff directly in Prod (scripting FTW, yay! </sarcasm>) and the code stank! Fixed width formats all over the places. You were lucky for finding delimited interchange formats. Live interfaces? Forget about it! Scheduled nightly runs! Unfortunately I can't say where I worked or on what but you would all recognize (and even your non-techie friends) some of it but not other parts (because the company ownerships aren't widely publicized and it's not anything that's "usually" on HN).

Inferior? In some ways yes, in other ways absolutely not at all. Their database and application was able to do things you could only dream of. This was (is I guess) an application that is/was used 24/7 all around the globe since ~30 years ago by now, which had excellent backwards compatibility (usually going back about 3-4 versions of the DB schema - full version history on all tables). Of course this was all in-house, not out there on the web. Even though the code stank and I cleaned up a lot of the parts I worked on in my years there, it was a marvel of engineering if you think about that. Some of what they were able to do 30 years ago, I still can't do at my current company! On the other hand, some things that are completely normal at my current company were and probably still are unthinkable in that place!

I am really thankful for having worked at that company as my first job. Even though at the time I probably didn't fully recognize this, it taught me a lot of perspective that I can use to this day to inform my thinking and decisions and ultimately helped me end up in the position I have right now. This was a team of 6 with myself and the team lead included. This was for the FE (fat client in a language many people won't even recognize or only by name) and the BE (scripting languages of various types).

[john_moscow]

I think, there are different aspects of quality. What you are referring to is the increased adoption of unit standardized techniques (unit tests, abstractions, continuous integration, etc). What the OP was referring to is the reduced understanding by the developers of why they are using each technique, and increased leanings towards just copy-pasting something from StackOverflow, or blindly cargo-culting something that a neighboring team does.

It is somewhat similar to all other economies of scale. Like AdWords, where you are one click away of being connected to thousands of ad publishers, but if the algorithm says "no", you get banned and will never get a chance to talk to a person. Like modern electronics where you can buy a device assembled in Philippines from parts made in China and designed in the U.S. for a fraction of a price of making it locally, but if a single $0.08 capacitor blows up, you're stuck throwing the entire thing out because the pipeline is not optimized for repairs.

[pornel]

I don't think we have reduced understanding of techniques. Software always had fads and programmers using them without understanding. The "Architecture Astronauts" article is now 20 years old! https://www.joelonsoftware.com/2001/04/21/dont-let-architect... And before that you could find rants that the real programmers are supposed to be using assembly, not high-level languages for noobs, like C.

And the examples you present are not cluelessness, but economies of scale fully utilized.