This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: Every time you fix a bug you risk introducing another
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
I read this article today called Why we all sell code with bugs, I actually read the article in the newspaper which had a link to his site where I found the full article http://software.ericsink.com/articles/Four_Questions.html
if you have read my blog recently (hello, is there anyone out there listening, looks like I'm blogging to myself again) you will know that I have recently been stopped abruptly by bugs other developers have put in. The bugs recently have been added whilst fixing other bugs, so the title of this piece and a quote from the article is entirely accurate in my experience.
The most dangerous bug is the what I call the unwanted side effect bug. It involves the changes you have made to fix one bug have unwanted side effects which then makes one or more bugs pop up else where in the system.
In my experience everyone knows there are some bugs in the system and sometimes they aren't high priority merely because they are not effecting the fundamental use of the software. Bugs can also be ignored if there is an easy work around for them, some times is safer to do this rather than wade in the code and fix it. The recent group of bugs have been because a developer has bravely/foolishly changed some of the core classes. It goes without saying that if you change a class that is used all the time then it increases the chances of you putting in a bug. Basically more interaction a class has in your software the increased chance of a bug popping up after you change it's code. The article explains why the company he works for would release code with bugs in (apart from not having any choice because code will always have bugs in, surely?)
"1. You release with known bugs because you care about quality so deeply that you know how to decide which bugs are acceptable and which ones are not. 2. You release with known bugs because it is better to ship a product with a quality level that is known than to ship a product which is full of surprises waiting to happen. 3. You release with bugs because the alternative is to fix them and risk introducing more bugs which are worse than the ones you have now."
The article says that basically it all boils down to the title of this blog
"Every time you fix a bug you risk introducing another"
The article has a good section on Should we fix the bug, this is the criteria they use to grade if they should fix a bug
Question One
When this bug happens, how bad is the impact?
Severity
Question Two
How often does this bug happen?
Frequency
Question Three
How much effort would be required to fix this bug?
Cost
Question Four
What is the risk of fixing this bug?
Risk
It's amusing reading the list because a lot of bugs, minor unimportant bugs get fixed merely because the developer thinks its going to be easy and an easy win for the team, whilst at the same time some important bugs aren't fixed because people think it's going to be really difficult.
Why Ships Software with Bugs in it
I think there are more reasons you ship software with bugs in here are some of mine
1. You have put in some new features, the new features are overall worth more to the customers than the new bugs
2. Sometimes you have to release the software because of a deadline
3. The new release of the software fixes some old bugs
The article does have a small section on regression testing, you would think after the cock up of releasing 3 version in a week he would expand this section of the article. I'm going to try and get the developers to improve are practices. I am going to try and get them to write some unit test (junit) and I also want to get the process of a weekly build and test on a Friday maybe. I know this doesn't sound much but from nothing (which we currently have) to this two steps I think it is on the right road. It's also quite difficult to introduce testing procedures because developers don't like them. Also I work for a very small company where we don't have code cut off's and show by this blog entry Code Changes whilst installing - now that is last minute
Previous Topic
