The Software Crisis

> It's a nice coincidence when they do.

> It's catastrophic when they don't.

Well, generally, it’s not my experience. Most software out there is not critical. Many bloated crappy webapp might end up badly doing what user is expecting while sucking irrelevantly large amount of resources all day through with erratic bugs showing here and there, yes all true.

But this is not as critical as the software that handle your pacemaker or your space rocket.

Most software can afford to be crap because most projects are related to human whims for which a lake of quality is at worst a bit of frustration that will not cause a feeling of devastation or pure death penalty. All the more, I guess that most software developers out there are neither working on Sillicon-Valley-like money motivation, nor paying their bill with the kind of software project they love to build on passion. So this means most software that hits market are generated through exogenous miserable remunerations. Who will expect anything else than crap to be the output of such a process?

Doctors and lawyers deal with people and everyday problems that are easy to turn into a interesting story. I don't see many contract lawyers or radiologists as protagonists - it's ER docs and criminal law.

Software development is about rigorously talking to a computer all day, either solving mundane solved tasks in a new application, or problems that you can't even grasp without a technical background. I'm a developer who started programming as a teen over 20 years ago for fun - and I'm bored out of my mind with most of the work - I don't even try to talk about it to non-developers because I know it's about as interesting as accounting, more people would get useful info out of their stories.

    Projects running over-budget
    Projects running over-time
    Software was very inefficient
    Software was of low quality
    Software often did not meet requirements
    Projects were unmanageable and code difficult to maintain
    Software was never delivered

When we press the power button on our computer and it gets to a desktop, our computer has already run through hundreds of abstractions. Just at that desktop it is already the most complicated machine we have or will interact with all day. This happens billions of times a day, all across the world, and mostly flawlessly. And that's just one tiny example.

I really don't like missing stairs.

We're very removed from the usage of our software, and experience it in short-form (hopefully) actionable signals that we use to inform our development process. We don't get to appreciate the real pain in this "death by a thousand cuts" unless we can somehow switch bodies with a new user.

I see programming as a trade, however, and we do have the power to govern the quality of our software. There are, however, incentives, financial or not, that can get us to look the other way.

In the case of Scrum, Scrum is implemented because it gives managers and stakeholders some semblance of observability and control over the software development process. Granted, Scrum shops are merely cosplaying at implementing a rigorous, controlled methodology, but if you take that semblance away you will have angry, frustrated decision makers who resent the software teams for being opaque and unwilling to commit to budgets or schedules.

In the case of abstractions... maybe there are a bunch of junior devs who just can't learn the complexities of SQL and need an ORM layer in order to reckon with the database. (I worked at a software shop where the most senior dev was like this; part of the reason I was brought on board was because I knew how to munge the PL/SQL scripts that formed part of their ETL process.) Maybe one part needs to be completely decoupled from another part in order to allow, for example, easy swapping of storage backends, or the creation of mocks for testing. Maybe some architect or staff SE is just empire-building, but at any rate they're way above your pay grade so the thing will be built their way, with their favorite toolkit of abstractions and advocating for the use of fewer abstractions will get you nowhere.

If you're working on a team of John Carmacks, great! You will be able to design and build a refined jewel of a software system that contains just the right amount of abstraction to enable your team of Carmacks to maintain and extend it easily while still running smoothly on a 386. Unfortunately, most software teams are not like that, most customers are not like that, so the systems they build will develop the abstractions needed to adjust to the peculiarities of that team.