One of the hardest things to accept, as a justice-loving maker of software, is that a perfectly engineered and beautifully designed piece of software can go completely unused. Similarly, a lot of the software on which the world relies a great deal can be terrible — riddled with poor design decisions if not outright and undeniable bugs. This seems to be a fundamental frustrating truth about software.

What Do We Actually Mean by Bad Software? 🔗

One of the first and most important reasons that bad software succeeds (and good software fails) is that we don’t all agree what “bad” means. Most everyone would agree that software which claims to backup your computer and instead corrupts your data at random and fills volumes more of storage with apparently successful backups which don’t contain your data is “bad.” But there’s a large middle ground between that hypothetical case and most software that we developers call bad.

• Is something bad if it works well for its primary users but is a pain to extend, change, or develop against?
• Is something bad if it serves its purpose exactly but requires hours upon hours of training to become effective in?
• Is something bad if it works reasonably well, is relatively intuitive to learn, but is very very unnecessarily slow in actually performing its intended operations?
• What if it does the job but is really ugly looking?
• Or does the job 95% of the time and then dies fatally and takes the system it’s on down with it the other 5%?

Because all of those examples are sanely put into the category of “bad software” it’s clear than one of the reasons that bad software does better than you’d expect from the label is that people don’t agree on what makes it bad. If you think a piece of software is bad because its graphical user interface is unsightly, and I think a piece of software is bad when it manifestly fails at its intended function, we’d probably have differing opinions of an old Swing (Java) app that a business relies on.

When Bad Software is Good 🔗

This conflict of understanding is at the heart of why bad software succeeds. A business person’s priorities are likely to be different than a developer’s. End users’ priorities are likely different than both the business owner and the developer. What one regards as great another thinks is alright and another likely considers “just plain awful.” That’s the heart of the issue.

Most developers who are first exposed to it understandably hate WordPress. As a development platform it is, at best, a bit unconventional. Its code was largely written a long time ago with some nontrivial number of last decade’s design decisions still going strong. But because the platform’s priorities are on user ease and continuity, it still works on an old shared hosting account running PHP 5.2 (which hasn’t even had security releases for the last few years). And all the old templates and extensions (or themes and plugins in WordPress terms) still run fine on the latest version.

You can disagree with the WordPress team about their priorities, and you can think that their software is just irredeemably bad, but you can’t really get past the fact that it continues to be used by a large (and seemingly still growing) number of end users who find it easy, comfortable, and powerful.

Why Bad Software Isn’t Going Anywhere 🔗

Fundamentally, the primary driver of the proliferation of “bad” software is that there are people with different priorities making decisions that affect the end product of a software development or purchasing process. And typically, those groups aren’t in alignment about what the goals are and what success looks like.

The way out of bad software is deep alignment at all levels and from all stakeholders about what a given piece of software is looking to accomplish, who it will benefit, and what a “good” version of that software will be. When it’s reached that vision, everyone ends up thinking it’s good, not just the most important and powerful stakeholder whose vision is realized.

Fundamentally, clean, well-tested, well-documented, and instantly-comprehensible code only matters to developers. To the business it’s about whether or not it provides value and helps in money-making matters. To the administrator, success typically looks like five nines of uptime (99.999%). To the end-user, what matters most is likely to be ease and delight. But each of those stakeholders’ goals can easily shunt aside the others in the inevitable contest of priorities.

Making good software for all the stakeholders is a political balancing act as much as it’s a matter of software craftsmanship, agile practices, TDD, or anything else. And aligning everyone’s vision and work is just as hard on a software team as it is on any other. Until all stakeholders’ visions are aligned about their goals, priorities, and success conditions, someone will always feel like they’re forced to deal with “bad” software.