admin | 
10 18th, 2008| 
I’ve been thinking a lot about software release quality lately and from a product perspective determining software acceptance criteria. Especially, in the web 2.0 world where it is more acceptable to move quickly and use your customers as your test team supported by an active community team. I’ll admit, up front, that I have a pretty high bar on quality and that has driven me into conflict on more than one occasion with my bosses and my own teams.
The question is, can the drive for quality put asunder the efficiency that agile brings to the table; and, when does the investment in quality break down?
Scott Ambler at Agile Modeling coined the term “Just Barely Good Enough” or JBGE. He says:
When you are working on something and it isn’t yet sufficient then you can still invest more effort in it and gain benefit from doing so (assuming of course you actually do work that brings the artifact closer to it’s intended purpose). However, if an artifact is already JBGE (or better) then doing more work on it is clearly a waste: once an artifact fulfills its intended purpose then any more investment in it is simply busy work … it is clearly possible for the value to be negative before the artifact becomes barely good enough although for the sake of argument I’m going to assume that you do a good job right from the beginning [my emphasis].
I emphasized the last sentence, because that is really the variable of consequence. All the analysis in the world about measuring value against effort is useless if you can’t be confident that your engineering team is not only doing a “good job”, but being enabled by the development practices to succeed at their efforts. And I think this is really where the wrong turns happen that cause poor quality practices and products to emerge.
Remember, it is the intended audience for the software that determines JBGE, not the engineer and not even the product manager. The quality process must measure against a quality index that meets the desires of the client. It is not sufficient to argue that the client always wants “perfect” software, because most clients who are trained to understand an iterative software development process will accept the fact that their needs will be met in a timely manner albeit not immediately.
It is premature to talk about What is Good Enough, until you understand intimately the issues of your customer.
