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 is that we don’t all agree what “bad” means.
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% or 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.
Fundamentally, clean, well-tested, well-documented, and instantly-comprehensible code only matters to developers.
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.
Related Posts
Image Credits: elwillo
Security considerations is something that is changing this landscape, even if slowly.
You just can’t make a complex piece of software secure.
Simple is beautiful.
With your example WordPress, it comes down to the interest of the vendor. Many, many, many companies out there preach WordPress because it is very easy to deploy and do basic customizations of. You can sell a website for the same amount of money you used to charge, but now it takes a lot less time, i.e. it’s in your interest to tell the customer how great WordPress is.
The thing is that ‘bad software’ is a moving target.
What seems great today becomes ‘bad’ and outdated tomorrow, because, guess what – things change.
Naturally when someone who’s been weaned on trendy new technologies is exposed to a piece of software that was put together 10 or 15 years ago, they will go, ‘this is shit, this is all wrong, this is bad and unmaintainable’ – but at the end of the day it’s really childish. It’s sort of like all those people that bashed COBOL back in the day, but guess what there’s legacy COBOL systems that have been running and delivering value to customers for decades on end.
No piece of software is perfect but as long as it does what it’s supposed to, it’s good enough and good enough is always gonna win against ‘perfect’ for the simple reason that ‘perfect’ is an unattainable goal.
The success of bad software is Stockholm Syndrome (http://en.wikipedia.org/wiki/Stockholm_syndrome).
Assuming it was sufficiently expensive for not being able to get rid of, or that the user base is so huge that abandonment is not a reasonable decision.
The head in the sand, the problems are forgotten and the wrong software is kept alive because abandonment is a cure worse than the disease for various reasons, mainly cost.
Choosing WordPress as an example is not very brave. The world is full of paying bad software that have been successful, are cumbersome and cost an huge amount of money to maintain because they are B.A.D. Just to mention: SAP and Oracle!
Stakeholders do care about cost of maintenance, alterations, extensions, porting and debugging though. And all these rise exponentially with the size of the code base if the code is Bad. As a software developer, you’re best of to keep them out of the loop though, when you want to spend time refactoring. Just tell them it’s gonna be 2 weeks to fix a bug, while you spend it mostly on refactoring. Don’t give them what they ask for, give them what they need.
What is your opinion about joomla, especially that you have mentioned wordpress?
The thesis of this article was first proposed by Richard Gabriel in 1989:
http://en.wikipedia.org/wiki/Worse_is_better
@Dave – by your definition that makes WordPress “good” software.
Follow the money. Time To Market is the biggest factor. A good marketing department can sell promises. Like the line from the movie Elf when the book publisher discovers they are about to ship kids books with blank pages – “Ship it! Who cares what happens to a friggin pigeon.”
There really is no excuse for poorly designed software and it has nothing to do with user priorities or business requirements.
Bad software gets produced simply because bad management simply does not care about the excellence of their products, which has little to do with their supposed requirements but more to do with their levels of incompetence.
The fact that bad software succeeds is a result of the fact that the interfaces are acceptable to most users even with all of the issues and problems.
And I agree with the other responders here that WordPress is a poor example for this argument. First of all, it gained is popularity early on in the Internet age and has remained free for use since its inception. It offers a variety of options and has been improved over the years. That being said, the internal designs may be lacking in finesse but I doubt that its reliance on PHP is a factor in the argument that it could be considered a bad product. PHP is\was no different from “Classic ASP”, which could be easily made a mess of if it was not designed with modular compartmentalization in mind, which can be very easily done with both products.
No, really bad software is quite apparent in our industry. This is software that simply does not work to expectations but is accepted all the time since managers who do not care have their user-communities at their mercy. This is especially true in all corporate development where this issue is at its most serious since product quality is never an important issue…
The sociology of software usage has something to do with this. “Bad” software survives because it gets to market first, and becomes a linchpin of exchange. From that point forward, it’s bad design makes it almost impossible to unseat because the idiosyncrasy of its interface makes it almost impossible to emulate by software that behaves robustly.
“Bad” software succeeds because A. Nobody complains B. Nobody knows who to complain to. C. Managers decide the cost/benefit of fixing it is too high. D. Users have no clue it is “bad”. Hmmm, put D where A is and shift the others down one. See, I didn’t want to put in the effort to fix my “bad” statement! 🙂
Bubble sort is one of the staple teaching examples of coding. No-one seems to mention that 150 million int values can be sorted in under 30 seconds with the OTS sort routine, while bubble should take centuries. OTS appears to use quick sort methods because my routine seemed to consistently run about 1.6 times slower. That is, with randomly generated values or sorted arrays. With unmodified arrays it was about 1.2 times slower.
All software is some gradation of Bad. I mean Linux is “bad”, MySQL is “bad”, MongoDB is really “bad”, Windows is “bad”.
I think what developers need to accept is that “…perfectly engineered and beautifully designed piece of software…” is by definition a myth. Just that word “perfect” is simply untenable.
And that’s really it. Good software satisfies the primary user’s needs. Great software satisfies the secondary user’s needs. Excellent software satisfies the Developer’s needs.
And it’s neither “good” nor “bad” nor “perfect” it’s just the quest for better. Developers who fail to accept this will simply be angry at users and managers and code forever.
The only part of this I’m uncomfortable with is the assertion that ‘Fundamentally, clean, well-tested, well-documented, and instantly-comprehensible code only matters to developers.’
That’s a great sound-bite, but it’s true only to the extent those aspects don’t add business value – and could easily be adopted as a mantra of excuse by lazy developers. Yeah, it certainly gets taken too far all the time, and is responsible for waste in our industry. But on the flip side, truly shitty code delivers negative business value in the form of increased time to market (sometimes indefinitely), and has a nonlinear and difficult to forecast variable cost.
As Mr. Hayes indicates throughout the article, the real trick is knowing where to draw the line between shitty and perfect — and aggressively seeking a shared vision of that among the stakeholders.
If you just substitute ‘perfectly’ for both instances of ‘well’ in that one sentence, then I’m totally on board 100%. Otherwise someone’s going to quote that back to me as justification after tanking some major deliverable someday, and I’m going to end up needing anger management classes.
Pingback: Let’s call the whole thing – software | Ti Brown blogging
Bad software occurs because profit is king. Developers are worked to the bone by stakeholders only interested in output and features. Rather than well designed stable products.
Put the same legal quality requirements on software as on other industrial products like cars: design and manufacturing errors have to be repaired for free by the manufacturer or vendor over the entire lifetime of the product and if these errors cause dammage, the manufacturer is responsible. This will prohibit software manufacturers to transform their custommers into unpaid guinea pigs.
Pingback: 为什么糟糕的软件成功了 | 腊八粥
Pingback: 为什么糟糕的软件成功了 | 我爱互联网
Pingback: 为什么烂软件大行其道而好软件无人问津？ | 我爱互联网
Pingback: 为什么烂软件大行其道而好软件无人问津？ | 爱闹 | 程序笔记 anool.net
Pingback: 为什么烂软件大行其道而好软件无人问津？ | 大分享网
Pingback: Your Code Should Be Comprehensible: A Simple Case Study - Press Up
Pingback: 为什么拙劣的软件也会成功？ | 我爱互联网
Pingback: 为什么拙劣的软件也会成功？ - 合智社区
Pingback: Ternary Operators Considered Harmful - Press Up
Pingback: Our Thoughts After Six Months with SiteGround as Our Exclusive Host | WPShout.com
Thank you for this very clear point of view. I’m currently reading Tom Gilb’s Competitive Engineering book, and he tries to address this multiplicity of stakeholders by quantitatively defining goals for different aspects of the product or system. This then allows to track the progress on everyone of these goals, using a spider graph for example.