This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Re: Investing in Quality, Bugs Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

Coté made the remark that bugs hold constant, meaning basically that every system introduced to control bugs becomes a source of bugs a well, and overall bug cost at any time for any mix of developers, systems, and applications is more or less constant (though different groups can easily have different rates). This struck me as very true at the time and was very discouraging. I was having trouble reconciling the empirical evidence of what I'd seen with what I assumed was a given regarding the value of quality.

That's pretty much what I was talking about. Part of the reason they're constant is because the code you put in to fix bugs can itself contain bugs, but there are others reasons as well:

• Each release, you (should be) adding new features to your product. New features mean new code, or, at the very least, new ways of using old code. This opens the door for more bugs.
• Once you've fixed all the "real" bugs, all the "fake" bugs will start being reported as bugs. This is a little play on what exactly a bug is: really, these "fake" bugs are feature or enhancement requests. For example, as Zane points out, when you have end users that aren't processing a high volume of data, it's OK if your data processing takes 8 hours. But, when you get end users that do want high volumes of data, it not OK. Thus, the (now) poor performance is a "bug."

Really, those are kind of the same: when you add new code, you get new bugs. As the goal of software done as a business (and most other software as well) is growth, adding features and getting more customers is part of the process. Thus, if you're always growing, your rate of bugs will remain somewhat the same.

This thinking is really based on that old theory that "the work required will fill the time available" (or however that's phrased). Which itself is based on, I guess, that thermo-dynamics stuff about nature abhorring a vacuum and always seeking to fill "empty space."

What's most important is reacting to this "fact." As your product grows, you must equally grow your support staff and efforts. Indeed, one of the "hidden features" that any growing product needs is the ability to better aid in support. Not only does this mean more people and time spent on support, but also actual features in the product.

For example, if your application keeps logs, you should be logging anything that even remotely seems like it'd be helpful in a support situation. More importantly, (1.) you should be keeping logs in the first place, and, (2.) you should make acquiring the logs easy, whether it's by allowing the customer to easily copy them or, better, your product provides some "bundle up supports info" button somewhere that'll Zip them all up to be emailed, FTP'ed, etc.

(I don't have any hard facts for all of this, of course: we don't use those in the programming world ;>)