Imaginary Problems Are the Root of Bad Software
Just because they’re fun to solve doesn’t mean they’re relevant
You can read this article on my own blog, if you prefer that to medium.
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
