Imaginary Problems Are the Root of Bad Software
Just because they’re fun to solve doesn’t mean they’re relevant
There are many factors which can be a catalyst for bad software: from the tools being used, to team communication, to the personal stake developers have in its success, to the testing methodology.
I propose that there is one problem chief among them, an impetus for bad software from which almost all others take root: imaginary problems.
Most complicated or broken software is not designed to be overly complex or dysfunctional. It’s just designed to do something other than its intended purpose.
Let’s say you’re a podcast host who wants a custom website where you can sell your promotional products, make advertising money without a third party cutting in, and, most importantly, deliver podcasts, videos, and blogs to your audience.
The requirements for your little web-app might look something like this:
- Fast load time in North America, with real-time podcast streaming and downloads
- Doesn’t crash or freeze in the first 15 minutes for 99.99 percent of users, preferably never crashes or freezes
- Integrates well with Google Adwords and maybe some other third-party ad providers as well, if there’s time
- Dynamically links to the latest products in my Zazzle shop and, if possible, gives recommendations to users based on the content they’ve consumed
- Integrates with Facebook live player. If it’s easy to create an alternative solution for streaming that doesn’t require Facebook, even better
You give these specs to a team of contractors, and you chat about them a bit. It seems that everyone is on the same page. Yet, when they return with the Minimum Viable Product two months later, your face turns red. You’ve just wasted $15,000 on a piece of garbage; you want your money back.
The first time you open the app, the screen freezes. You ask how to select what kind of ads should be allowed to run on the site and are pointed to an ugly, hard-to-understand custom user interface (UI). Half…