|
12345 |
- title: Software has bugs. This is normal.
- url: https://m.signalvnoise.com/software-has-bugs-this-is-normal-f64761a262ca
- hash_url: 81f2337ef46ed130b13bc0ba50f809d5
-
- <div class="section-inner layoutSingleColumn"><h3 name="d75a" id="d75a" class="graf--h3 graf-after--figure">Software has bugs. This is normal.</h3><p name="f634" id="f634" class="graf--p graf-after--h3">Disappointment occurs when expectations don’t match reality. And our expectations for software quality are profoundly unrealistic. Thus, lots of people are continuously disappointed — even enraged — by software bugs. They shouldn’t be.</p><p name="4a47" id="4a47" class="graf--p graf-after--p">The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).</p><p name="01a8" id="01a8" class="graf--p graf-after--p">How do you think the market would receive the iPhone 7, if its headline improvement was cutting 1/3 of the features to shrink the code base so it’d have fewer bugs? Yeah, I thought so. While people may get excited in concept by “stop the train, we need to fix the tracks” directives for software development, it’s not what they would buy.</p><p name="cab1" id="cab1" class="graf--p graf-after--p">Well, but then there’s the argument: Apple is so rich, can’t they just hire more developers and testers to fix all the bugs? To <a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month" data-href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_mythical_man-month" class="markup--anchor markup--p-anchor">paraphrase Frederick Brooks</a>: No. Software development doesn’t work like that. Throwing ever bigger teams at problems usually just makes the problems bigger still.</p><p name="8778" id="8778" class="graf--p graf-after--p">Bugs are an inevitable byproduct of writing software. Sure, there are all sorts of techniques and potions that promise to decrease how many of the damn critters run about, but only the comically hyperbole pretends that complete eradication is possible.</p><p name="04bf" id="04bf" class="graf--p graf-after--p">Once we accept that simple fact that software = bugs, we can progress to understand why fixing them may not even be that important a lot of the time. The absence of bugs is simply one parameter of success in software, but not even close to the most important one (with some exception for life critical systems).</p><p name="e8d7" id="e8d7" class="graf--p graf-after--p">Useless software can be entirely bug free, yet remain entirely useless. Useful software can be ridden with bugs, yet remain highly valuable. Or, the value of software depends far more upon the problem it solves than the quality by which it does so.</p><p name="50e5" id="50e5" class="graf--p graf-after--p">Sometimes the dichotomy isn’t that black and white, of course. You could have two pieces of software that solve the same problem, and it’s reasonable to think that the one with fewer bugs would do better. Though even that simple statement is often laughably disproven by the market. Factors such as existing adoption, integrations, brand, and fun often trump quality as well.</p><p name="0704" id="0704" class="graf--p graf-after--p">Given that there are so many factors more important to the future prospects of a software package and its makers, is it really that surprising not every bug gets “drop everything, we gotta fix this” priority? Of course not. But we, as users who hit a bug, still constantly pretend that it is.</p><p name="5c73" id="5c73" class="graf--p graf-after--p">It’s really the pinnacle of myopia when we as users demand and demean software makers to fix our pet bug, just because we hit it, and just because it may have caused anything from a slight annoyance to loss of some time.</p><p name="a3cf" id="a3cf" class="graf--p graf-after--p">The value of a any given bug can be rated by the number of users affected times the criticality of the issue. Lots of users are losing all their data due to this bug? Okay, then, Very Damn Important! Fix it NOW! Lots of users are a little annoyed or confused by this? Probably should fix it some time soon. A few users have to spend another 30 seconds on a work around? Unlikely to get fixed any time soon!</p><p name="bcc0" id="bcc0" class="graf--p graf-after--p">Software organizations that stay in business triage their backlog of bugs like that. They do not drop everything to deal with any damn bug. As the economies of scale kick in, so does the magnitude of consequences from such triaging. Large software packages and organizations will have hundreds if not thousands if not TENS OF THOUSANDS of open bugs of various criticality. THIS IS NORMAL. THIS IS EXPECTED.</p><p name="55b0" id="55b0" class="graf--p graf-after--p">This is not a call to give up on software quality, quite the contrary. This is a call to remove the highly charged emotional responses of encountering the world as it should be expected to spin. Demeaning developers, questioning their professionalism (whatever that means!), or feigning outrage at that which ails all software makes everyone, including users, worse off.</p><p name="3552" id="3552" class="graf--p graf-after--p graf--last">So next time you hit an annoying bug, give it five minutes before you fire off that indignant tweet. Marvel at the miracle it is that anything as complex as a modern piece of software works at all! Consider the billions of instructions our work-horse CPUs have to get just right for you to enjoy the splendors of computing. Have some sympathy for man and machine.</p></div>
|
