Achieving Immediate and Continuous Bug Fixes in Agile Development

As I mentioned in our blog overview, most development shops spend noticeable time prioritizing and dealing with bugs. However, that effort only manages the symptoms. It can be more useful in the long run to look at the operational side of development. An interesting issue is the time that elapses from when a bug enters the system and when it is detected. I have been in situations were this time was measured in minutes. Then developers could quickly learn from their mistakes, make immediate corrections, and move on. They learned and over time produced fewer and fewer bugs. Then we did not spend time prioritizing and dealing with long lists of bugs.

Bill and I had a conversation going into more depth on how this might work.

Bill: How do you get the bug reporting time down to minutes? I am used to seeing many bugs getting all the way out to users as an accepted byproduct of software development. Some vendors are famous for this.

Jeff: The first thing you need to do is to establish the practice of continuous build, or better continuous integration. Most successful Agile development
shops have this practice in place. This means that every time a developer turns in their code, the application is rebuilt and tested with the new code. So you are able to quickly see if the new code brings in any unwanted behavior, aka bugs. This integration often takes a few minutes to build a typical change. The book Continuous Integration by Paul Duvall, Steve Matyas, and Andrew Glover is a good resource on this topic.

So the first part is having the ability to quickly turnover the integration of new and old code. The second step is to have good unit tests. These tests should be part of the automatic build. If a unit test fails, the ‘build’ fails. If you have unit tests in the area being changed, the effects of the bad code will show up right away.

Bill: I have often heard of unit tests but usually just assume I know what they are. I think I need to make sure I know what you mean here.

Jeff: Unit test are the lowest level of tests. They test classes and methods and small assemblies. They look at code function to see if it does what the developer wants it to. Functional tests on the other hand look at code to see if it performs what the customer or end-user wants. Unit test are designed to run very fast and look at all the code on a specific section of the application. Test coverage measurements should be made on unit tests.

If you use a technique call “test first,” then no line of code is written except in response to a failing test. That means that there is not a lot of code in the system that was produced without a test informing the code’s development. This gets interesting because what this means that every line of code has a test associated with it. So if something changes the code later the unit test can see if anything breaks.

Because the unit tests are so fine grained you will know right away what the problem is without having to debug. Debugging is figuring out what is wrong and with unit tests you know what is wrong. So if you make a code change and it breaks right away you know right away the cause. You still need to understand it but you do not need to spend time finding it.

So the combination of continuous build and unit test allow you to get to the condition of bugs being found right away. In the particular case I was thinking of we did not need a bug tracking system. In this effort we had twelve developers over eighteen months and only had about five bugs at any one time. There was no need to prioritize bugs. We said all bugs are important and need to be fixed right away.

Bill: So this makes total sense to me. Why doesn’t everyone do it?

Jeff: There are a couple of reasons. One reason is that historically we have considered testing not part of development. We have considered testing as something done by QA, often by a different department. Code got thrown over the wall for someone else to deal with and quite a bit of development was done before testing occurred. Responsibility was passed on and not shared.

The other reason is that we do not tend to measure debugging effort so the cost is not apparent. It is almost always much more than people think. When we do not measure fixing bugs there is not any drive to improve the process. Also, folks just assume there will be lots of bugs. ‘That is just how software is.’ Well, it does not have to be that way and I think it is time to change our attitude.

Bill: So is the concept of immediate fix one of the cores of Agile development?

Jeff: Let’s say that most successful Agile teams just do it. One of the practices in extreme programming (XP) is the concept of collective code ownership. In this case an individual does not have ownership of code. So no one can say, “well I cannot fix this code because it is someone else’s code.” So when in Agile we all own the code so if I see a bug, I just fix it.

Comments

[mbt online]

well this blog is great i love reading your articles.

[Moncler outlet]

Thanks for the comments.Now all became clear, I thank for the help and I hope to see more such articles.

[Moncler outlet]

Good point. I hadn't tohugth about it quite that way. :)Your article looks nice!