David Heinemeier Hansson

David Heinemeier Hansson -

Software has bugs. This is normal.

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.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).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.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 paraphrase Frederick Brooks: No. Software development doesn’t work like that. Throwing ever bigger teams at problems usually just makes the problems bigger still.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.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).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.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.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.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.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!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.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.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.I originally wrote this in 2016. Seven years later, it's just as true. HEY has bugs. Basecamp has bugs. Hopefully fewer than the competition, hopefully none of them critical.

软件质量的期望与现实相差甚远,因此许多人对软件缺陷不断失望甚至愤怒。要确保软件质量完美,唯一可靠的方法是减少软件的功能,花费大量时间精雕细琢,但这种方法很少与商业成功或程序员动机兼容。软件开发不是把更多的团队投入到问题中就能解决的,缺陷是编写软件的必然副产品。软件的价值取决于它解决的问题,而不是它的质量。软件组织会对缺陷进行分级,大型软件包和组织可能有数以百计甚至数以千计的缺陷,这是正常的。这不是放弃软件质量,而是要消除对遇到缺陷时的情绪反应。

相关推荐 去reddit讨论

热榜 Top10

eolink
eolink
观测云
观测云
LigaAI
LigaAI
Dify.AI
Dify.AI

推荐或自荐