Software development bugs: How to identify and prevent them

No matter how talented the development team, bugs are inevitable in every software coding effort. In this Q&A, we find out from software developer Dror Helper the proper techniques to find those bugs early in the cycle, when they are least potent.

What types of bugs are typically introduced in each step of the application lifecycle?

An application lifecycle can be divided into five stages: requirements, design, development, testing and deployment. In each stage, a different kind of bug can be introduced. In the requirement stage, we can "forget" one of the requirements which would result in an incomplete product while a bug in the design stage would probably mean that the product does not work as intended.

During the development stage, there are also the bugs that keep appearing – regression bugs as the project progress. It becomes harder and harder not to "break" existing functionality when implementing a new feature and fixing another bug.

What are some reasons simple projects becomes too complex to manage?

As a project grows, it becomes more complex not only because more and more lines of code are written, but also because software tends to change over time. Requirements are added and changed, bugs are found and fixed, and customer feedback changes the product one small feature at a time.

Another key factor is the number of people working on that product. At the start of the product, only a few people are working on it, but as the project progresses, more and more developers, QA analysts and product managers are recruited to the project. As the number of people working on the same project increases, it becomes harder to keep the original design intact. Some team members might change jobs or transfer to another project, taking with them knowledge and expertise.

As the code base becomes larger, it becomes harder to manage, because not all team members know and understand all the aspects of the application they are working on -- resulting in a very complex project.

What can be done to prevent this?

Communication is a key element in keeping the product tidy and simple. All of the development team should understand the key point of the product and knowledge should be shared between the teams working on the product.

It is important to communicate major architecture key points and feature implementations to the whole team so that the resulting code will be consistent.

What are some practices that can be used to prevent the most common bugs?

Managing requirements is one of the simplest practices that has a very high ROI. By writing down all of the requirements and tracking them as they progress from design to development, testing and deployment stages.

Keeping the product with as little functionality as needed can reduce the amount of code that's not being used and prevent product bloat. Many Agile practices deal with how to develop exactly what is needed by working vertically and providing value to the customer after a few weeks of development. By showing working pieces of functionality to customers, we can verify that the developed product meets the business needs early in the development process.

Writing unit tests is another simple practice that has benefits not only for the development stage. Writing unit tests helps test the code and prevent regression bugs. But that's not all – the unit tests validate the requirements by running the code one piece at a time and checking the API by using it first by the developer who is responsible for it.

How can bugs be prevented from ever occurring in the first place?

It is impossible to prevent all of the bugs but their number can be reduced by applying unit tests, code reviews and pair programming where applicable.

Should bugs found during unit tests be tracked?

In my opinion, the unit tests are enough documentation and there is no need to track them in an external tool. I would recommend communicating to the QA team the bugs found so that they would be able to write better test plans accordingly.

Dror Helper is an experienced software developer that has written and designed software in various fields including unit testing tools. Dror’s blog can be found at http://blog.drorhelper.com where he writes about unit testing, Agile methodologies, development tools, programming languages and anything else he finds interesting. He is a software engineer at Better Place. He was previously a software developer at Typemock (http://www.typemock.com).