Project Scope and Bug Density

by Krishna on June 9, 2008

One important consequence of bug reports is that they not only affect your schedule, but also conflict with your priorities. Release of product features is negotiable to some extent. A critical bug seldom is. You have to postpone much of your planned work until the bug fix is released. That step requires you to perform the release management steps again, so your quality staff members are also involved and they cannot pursue other planned activities.

The other important problem with bugs is that every bug lowers the confidence of the stakeholders in both the product and the creators of the product. The bug does not have to be serious to reduce confidence. It can be a minor bug that is irritating or confusing or careless. Lack of confidence reduces the effort that users are willing to put in to learn the system.

There are many ways to improve quality in your project and reduce the bug count such as different forms of testing, code reviews, etc. But there is a certain limit to quality that you can achieve with the normal constraints of a project (available time and budget, quality of technical resources, etc.) Your limit may be higher or lower than other projects, but it exists, and you cannot improve the level of quality by performing more quality activities because the law of diminishing returns kicks in.

Assuming that you are operating at your highest quality level, the quality of your product is proportional to the size of your product. The more features and code it has, the greater number of potential bugs, assuming that bug-to-feature ratio stays constant. That is why the suggestion by 37signals to build less seems very attractive. 37signals has a more general (and sometimes controversial) philosophy than just reducing bugs, but let us focus on bugs for now.

It does not seem practical at first glance to reduce product size. After all, customers demand features. More functionality sells more products. And there is nothing more capable than a rush of customers leaving you for other products to increase product scope dramatically. But if we cannot reduce product features, what can we do?

One answer is to tightly integrate features instead of distributing them throughout the application. For example, instead of building different screens for displaying records for data entry purposes and for reporting, merge the two screens. Provide more information on a single screen instead of breaking it up into multiple tabs. Avoid wizard screens and make all your screens easily learnable for the beginner user.

So reduce the project size to project feature ratio. This requires more work because you have to create a more visually compelling and intuitive user design. And your code will have to be modified to make it more streamlined and able to implement more complex needs. But in the end, having an overall smaller code base and project size earns its reward in higher quality, greater consumer confidence and better project planning.

Comments on this entry are closed.

Previous post:

Next post: