Software development would be a lot easier without so many bugs. In a typical software application, there’s a never-ending stream of bugs as far as the eye can see. Some of the bugs make users’ lives miserable, some of them are annoying but can be dealt with workarounds, and the rest are mostly minor inconveniences. If that sounded depressing, I’m sorry, that wasn’t my intention, I’m only trying to survey the current software quality landscape not only as a software developer but a user.
When writing code, unless there’s the possibility of putting the lives of people in danger or losing a lot of money, software developers are often incentivized to produce code quickly since time to market is almost always deemed to be critical by the powers that be. So, developers write code that works anywhere between 0.1% of the time (works on my machine) to 99.9% of the time (mostly bug-free). Given that the actual application code software developers write is only a fraction of the total code that is running on a computer (there are many dependencies such as the operating system, databases, third-party libraries, web services, and so on), it’s next to impossible to expect 100% bug-free applications. But, we often fall far short of the hypothetical 100%.
To me, nothing is more frustrating than a critical bug in a feature you rely on, which had been working all this time, but the developers managed to break it in the latest update. How can they mess it up and release something so obviously broken? Aren’t the developers using their own software? The answer is… no, not really, at least not the way you are using it. They’re not the pilots flying the plane; they’re the engineers building it. In fact, as a user, you probably know more about the intricacies of your favorite feature than its developers do.
Since bugs are a part of life, you might be prepared to forgive a critical bug if they fix the bug quickly, but what if they don’t? A bug might only affect a small subset of users, so the developers might have a hard time reproducing it. Still, isn’t the developer’s job to anticipate all the things that could go wrong? The answer is, once again, not really. In an ideal world, where money is no object and you can spend as much time as you need to write high quality code, it may be possible to produce almost perfect software. But, we’re not living in an ideal world. If there aren’t many users who are willing to pay a premium for highly reliable software, then the financial incentive isn’t obviously there.
Can we still write mostly bug-free software even when the immediate financial concerns aren’t in our favor? After all, producing high quality software could, in the long run, turn out to be a significant competitive advantage since developers will be able to spend more time in improving their software than fixing bugs, which brings us to the use of the scientific method in software development, or more often than not, the lack of it.
The scientific method is about forming a falsifiable hypothesis and trying to refute it by finding at least one conflicting condition. In software development, however, a more optimistic route is usually taken. Yes, the code is tested to see if it works in certain conditions, but those conditions usually entail the happy path. Testing edge cases, the source of most bugs, is often a lower priority.
So, are we doing it wrong? Shouldn’t we pay more attention to finding and testing edge cases? The answer again lies in economics. The proper handling of a large number of edge cases means doing a lot of work that isn’t always appreciated by users who need a feature yesterday. So, what do software developers under time pressure do? They enclose the happy path code in a try-catch block, and return an “Unknown error” message if something goes wrong. You now know where those cryptic error messages come from.
It’s easy to criticize software that is full of bugs, but it might not make much financial sense to produce highly reliable software with only a few features if most users in your market prefer software that, despite having more bugs, offers twice as many.
If I’ve come across as someone defending mediocrity in software development just because the financial incentives aren’t there, that’s not what I meant. No software developer who takes pride in their work, by definition, wants to produce less than great software, but good engineering is a balancing game. You are usually given a time budget, and are expected to do your best within that budget. Good engineers know how to negotiate rather than doing blindly what they’ve been told. They might offer cutting or simplifying features in order not to spread too thin, and good management listens to what they have to say.
Related: