Software Bugs

by Krishna on March 25, 2006

If it is software, there are bugs. They are like roses and thorns — you cannot get one without the other. If you aim to build high quality software, the best you can do is to reduce bugs to a level where you can manage them instead of them managing you and the project timelines. Here are some practices that would help you towards that goal.

Strike a balance between people and process. You should have good processes in place. At the same time, hold your developers and testers to high standards. Don’t start pointing fingers when something goes wrong. Find the root causes and fix them. There are several good methodologies for software development such as Agile for small teams to CMMi for large organizations. Use what works best for your environment.

You must have good requirements specification, design and coding standards. If you rely on developers to build software using their memory of what you told them, you have placed your bets really badly. Even your best team member will forget important stuff. Conduct meetings for your team to discuss the requirements and design. Train them on the standards and the technology. Inform people about your expectations for the project.

Create and release builds frequently. Have a high ratio of testers to developers. The more testing and the sooner you do it, the more stable your application will be. During the first 25% of development, conduct testing on the standards defined for the project — that will make the rest of the project go more smoothly.

Prioritize your bugs so that you don’t get into an endless loop of fixing bugs. Some bugs can and should be pushed off to the next release. Find commonly occurring bugs and reduce their occurrence by informing the team through meetings and group email. You should also consider updating your unit test cases to handle such scenarios.

Build error tolerance into the product. To take an example from construction projects — Even if the beams and nails are not aligned 100%, things manage to work. Your software should consider mistakes by end users and recover. Applications using speech recognition are still not widely adapted because they are not able to tolerate mistakes or misunderstandings which human beings by their intuition and experience are able to overcome.

Involve your end users early in the development process, including requirements analysis. Select “good” end users who understand software development, are patient with bugs and provide constructive feedback. Do not involve users who are busy with other work or who are not knowledgeable.

Design and develop good smoke tests — these are quick tests for developers to quickly test scenarios most likely to break when they are changing a module. Unlike a full-blown regression test, this takes a whole lot less time and hence more likely to be adapted by developers. If there are bugs, the developer knows what change resulted in the error, unlike a regression test which may pick up several scattered bugs caused by several minor changes, each of which is now a candidate for debugging.

Finally, take responsibility for your role as a manager. It is your job to provide developers and testers an environment to be successful — this includes processes, training and regular oversight. Without getting into the trap of micro-managing, talk to your team members often. Allow them to speak honestly and openly about issues. Try your best to resolve them.

Comments on this entry are closed.

Previous post:

Next post: