 |
Articles Feed |
Categories
Archives
- July 2010 (5)
- June 2010 (4)
- April 2010 (3)
- March 2010 (2)
- February 2010 (2)
- January 2010 (1)
- December 2009 (1)
- October 2009 (2)
- September 2009 (2)
- August 2009 (1)
- July 2009 (5)
- June 2009 (2)
- May 2009 (2)
- April 2009 (8)
- March 2009 (7)
- January 2009 (2)
- December 2008 (3)
- November 2008 (5)
- October 2008 (4)
- September 2008 (6)
- August 2008 (4)
- July 2008 (5)
- June 2008 (5)
- May 2008 (4)
- April 2008 (2)
- February 2008 (4)
- January 2008 (2)
- December 2007 (2)
- November 2007 (2)
- October 2007 (2)
- September 2007 (1)
- August 2007 (3)
- July 2007 (1)
- June 2007 (4)
- May 2007 (7)
- April 2007 (2)
- February 2007 (3)
- January 2007 (3)
- November 2006 (3)
- October 2006 (3)
- September 2006 (17)
- November 2004 (1)
Ethical approach to Software Bugs
by: paul | April 8th, 2009 |
Software bugs are errors or omissions in the work we create. They are our mistakes as software developers. I am going to leave defining and dealing with bugs to a blog post I wrote last summer. I would like to take a closer look at software bugs, using an ethics metaphor to examine some of the rationale. For the sake of this blog, we fall into three camps: Software Utility, Software Relativism, and Software Craftsmanship.
Software Utility
“Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.” -- Joel Spolsky
This is the camp of software utilitarianism. I understand applying this rubric in terms of return on investment might have J.S. Mill turning over in his grave, but there is a strong correlation here. According to wikipedia, utilitarianism “is the idea that the moral worth of an action is determined solely by its contribution to overall utility.”
Let’s take an example using Mr. Spolsky’s argument. We need to be able to quantify in dollars the value of Bug X. It is worth $1,000 to the company, because the ramifications of not fixing it means we only lose 2% of our user base. The cost of fixing this bug is $3,000 worth of development time. According to Software Utility, this is a no-brainer. Let the bug go, find something more important and more financially inviting to work on.
The problem here is there are so many unquantifiable variables in the equation. How do you put a dollar amount on instability? When someone tries to reuse the code that has a bug in it, you are spreading the bug throughout the system, literally, like a disease. You can deal with smaller known bugs now, or you can have them bubble up as diseases later on, where the price of fixing them will grow much higher. The software craftsmanship approach means you don’t have to get into the tricky business of quantifying everything.
Software Relativism
I have heard that, “my team doesn’t test drive their code, and so I don’t.” This is software relativism. Famous moral relativist J. L. Mackie “argu[ed] against the objective existence of right and wrong as intrinsically normative entities on fundamental grounds unsure what kinds of things such entities would be, if they existed.” In software, this is saying that whatever works, works.
Or, “We try to keep the bug list low.” Specific practices will be chosen due to their ease or convenience, rather than due to their inherent worth. If I join a team that is making money writing software without testing it, I shouldn’t judge, but do the same. There are no objective rights and wrongs, just a series of things that will work for specific circumstances.
One of the problems is when you get into a negative feedback loop. When everyone is sprinting for the finish line and there are no objective standards, you are going to end up with junk at the other end. We need a threshold of quality we will not fall below. Otherwise you will end up with a system of piecemeal quality, with parts that are stable and parts that are not stable. This is arguably worse than an unstable system. Either way, if becomes costly to maintain or just plain unmaintainable. The software craftsmanship approach avoids this problem of relativity by placing minimum objective standards.
Software Craftsmanship
I am calling the third section software craftsmanship because it fits conveniently in line with the software craftsmanship movement. It is based on the ethics of Immanuel Kant, specifically his first formulation of moral theory. It stated, “Always act according to that maxim whose universality as a law you can at the same time will.” The classic example is dealing with lying. Can lying for the sake of some other good be considered moral? Kant says to ask yourself: “If everyone lied, would the maxim still hold?” No, our society functions based on a presumption of honesty. Well, if everyone overlooked bugs or shipped with known bugs would the maxim still hold? No, software functions based on the presumption of quality. The user expects the software to work. To me, this means as an aspiring software craftsman, I can not ship with any known bugs. If you make lying acceptable, your neighbor will start to lock their doors. I am afraid that many software users have already locked their doors. So, a software craftsman can not live with bugs in their system.
I ship with no known bugs. As Thomas Jefferson says, “In matters of principle, stand like a rock; in matters of taste, swim with the current.” Shipping with no bugs and cleaning up my own messes is a matter of pride and principle. It can’t always be done with ease or convenience. Sometimes it means fixing some obscure feature you are sure no one will use.
April 8th, 2009 at 08:44 AM
Well said! Nicely done. I think the third section is appropriately labeled, and not just conveniently labeled. :) It fits into the sort of Craftsmanship that Joel Spolsky discussed back in 2003.
April 8th, 2009 at 11:17 AM
In my opinion, the biggest problem with Joel Spolsky's quote:
"Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it."
is his use of the word "when".
I'm not as strict as you about shipping with no known bugs -- sometimes the ship date is imposed externally (e.g. there is a launch event planned), I might be dragged on to a project that has already launched and is a mess, etc.
However, I *do* think that it's a mistake to ignore bugs until they can no longer be ignored.
"A stitch in time saves nine," as they say.
April 8th, 2009 at 11:18 AM
In my opinion, the biggest problem with Joel Spolsky's quote:
"Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it."
is his use of the word "when".
I'm not as strict as you about shipping with no known bugs -- sometimes the ship date is imposed externally (e.g. there is a launch event planned), I might be dragged on to a project that has already launched and is a mess, etc.
However, I *do* think that it's a mistake to ignore bugs until they can no longer be ignored.
"A stitch in time saves nine," as they say.
April 8th, 2009 at 12:17 PM
Joe,
I think that if you keep a 0 sized bug list that when it comes time to release, that decision isn't as urgent. It is only when you have back loaded bugs that you would either have to sprint to finish or release with the product, that you have to make the tough decision of whether to release with bugs or not.
One thing we have done is follow the maxim, "No developer can start a new story if there is a known bug."
April 9th, 2009 at 02:36 PM
So if a bug incurs a cost of $1 over the lifetime of a product, but costs $10 000 to fix, do you fix it? And suppose the cost to fix is because the bug is inherent to the architecture rather than the quality of its implementation. Aside from this one issue, the software is perfect.
Isn't this like saying that a doctor will refuse to triage patients properly? They have to decide that the cost of treating one person is not worth the cost of not treating several others.
Every craft has that same tradeoff and adhering to the maxim that 'no bug is admissable' doesn't further our own craft.
April 9th, 2009 at 02:37 PM
So if a bug incurs a cost of $1 over the lifetime of a product, but costs $10 000 to fix, do you fix it? And suppose the cost to fix is because the bug is inherent to the architecture rather than the quality of its implementation. Aside from this one issue, the software is perfect.
Isn't this like saying that a doctor will refuse to triage patients properly? They have to decide that the cost of treating one person is not worth the cost of not treating several others.
Every craft has that same tradeoff and adhering to the maxim that 'no bug is admissable' doesn't further our own craft.
April 10th, 2009 at 11:45 AM
Jacob,
I think something that is inherent to the architecture is not a defect. I am speaking of omissions/mistakes that were made by the development team. This is one of the problems I encounter, everyone has a different definition of a bug.
Bug triage can have the effect of normalization of defects. This is the trap of relativism. You become normalized to things that you would not be normal. Bugs/defects happen, but they should not be treated as normal, they should be the exception.
I think there are constant trade offs in development, but when I(collective team) make a mistake, it is not subject to the same thinking that a feature or integration point would be.
January 12th, 2010 at 03:02 PM
I'm working on a textbook, Computing Essentials by Oleary, in which my author would like to use a screen capture of your article at this url: http://blog.8thlight.com/articles/2009/4/8/ethical-approach-to-software-bugs. He is using the screen to illustrate his point about software ethics. May we have your permission to use this screen in print and ebook versions of our textbook?
thank you.
marcy