Keyvan Nayyeri

Continuing my post series about the importance of hiring good employees for software projects, today I want to talk about the advantages of having a good developer in the quality and success of debugging stage in software development cycle. So far, I have introduced the topic and detailed different aspects of this topic for the planning, architecture, and development stages.

Now I want to concentrate on a very important stage in software development that is not taken serious by many software teams, and that is the debugging stage. Debugging is important because its quality can have such a huge impact on the whole project, and can disturb the integration and consistency of the code. There are many ways to debug a defect but many of these solutions are not appropriate. Some people spend more time finding the most relevant solution for a bug, while some other developers use the first solution that comes to their mind. Therefore, a bad debugging can challenge your projects as a whole.

I don’t want to go further than a single point in this post, and that point is something already written in the software development bible by Steve McConnell, Code Complete. In Chapter 23 of the second edition he talks about debugging, and as an implied part of the chapter he discusses the importance of skills for a good developer in the success and quality of debugging. What is stated in that chapter is all I want to say here.

One of the early sections of the chapter gives some statistical evidence to support my assertion. In a study between three developers that were good at debugging and three developers that were slow/bad at debugging, the first group have been able to debug the code in one-third the time, and inserted only as two-fifths as many new defects as the second group. Also the group of good developers found all the defects and didn’t insert new defects in correcting them, while the group of bad developers missed 4 of 12 defects and inserted 11 new defects in correcting those 8 defects! This study also shows that the first group have 3.7 defects left in their code, but the second group have 9.4 defects left!

As you see in the abovementioned study, there is a significant difference between good developers and bad developers in debugging.

Debugging is the art of recognizing a defect, finding its source, looking for the best solution, and applying the solution in the best form. Like any other task, they need a good level of knowledge and experience but what makes the importance of skills and knowledge bolder is the lack of comprehensive automated methods and techniques, and the necessity to be good at this work to be able to create your own methods for specific circumstances that you face with.

If you do great in the whole process of developing your project but don’t do well in debugging, and release your project with many defects, you actually have missed everything and all your investments in other stages are worthless.

As stated above, with a good developer on board, not only you develop a software with less defects, but also you find more defects, apply the best solution for them, and avoid adding new defects to your code.

In essence, with a good developer in debugging you do it once and in the best form, but with a bad developer you’ll end up with redoing many parts because the outcome is full of defects that need your attention and paying more to your developers to resolve them. So, even if you save your money and time by hiring a lower level developer in the earlier stages, your future costs don’t let you succeed.

As the final note that is actually my personal opinion, the growing number of software builds and the lower quality of software that we’ve been seeing in the past few years can be direct results of the lack of quality in debugging and testing stages in software development. Although newer software practices, specifically Agile Development practices, are built on top of frequent builds in the development cycle, this is something different from releasing a project and then dropping several minor and major versions in a short time after that just to resolve some defects found in your code. If you go back and forth, you should remember that solid software that we had in 90’s decade that could work well for a very long time, but after stressing on business plans and money stuff, many applications have become poor and weak.