The Mindset

Here’s a fictional scenario:

A Development Lead is assigned with a new project. She begins to analyze the requirements and does some rough design only to come up with the conclusion that the project should take approximately six months for a team of two developers. The Development Lead goes with this estimate to her boss. “Unfortunately”, her boss says, “you only have four months to accomplish this task… and we cannot assign more people to it other than the two people you already have”. Our Development Lead really had good intentions. She wanted to do this project right. But now she must find a way to make the project on time. Well, if we can’t have more resources, she says to herself, this must be a “Good Enough Quality” project. Let’s cut development time by not spending too much time on design and skipping Unit Testing. This will probably save about a month of development time. The rest of the time, we will just have to work harder. And… we probably won’t have enough time for extensive Code Reviews since we are working overtime as it is, but this is OK because we will deliver the product on time. Any major bug will probably be identified by QC anyway.

So, what is the problem with this line of thought? The first problem is that the project was not defined a-priori as a project that could settle for “good enough quality”. No body really knows what “good enough” is in this case. The project became a “good enough quality” project due to constraints, which have nothing to do with the customer expectation regarding the quality of the product.

In fact, this is what happens in most cases: the customer wants a quality product on time; the development team does not have enough time to do the job properly so a unilateral decision is made to compromise quality because “we can settle for a ‘good enough’ product”. Still, no one takes the time to define what “good enough” means for this concrete project: are two major bugs discovered on the customer site considered “good enough”? Is unmaintainable code, which will cause every new feature request to consume twice the resources that it should have, “good enough”? Is a security breach in the product, which can cause severe damages to the customer, “good enough”? Without explicitly defining the expectation from the product, you will end up with a frustrated customer, and developers who don’t know what they are expected to do.

But the situation gets even worst. Our Development Lead decided to take the “good enough” approach. But will she be accountable for this decision when something “unexpected” happens? In most cases, when a major bug is revealed on site the developer is the one everybody looks for, although she might wanted to do a better job to begin with. The same applies to situations where a new feature is needed and everybody is amazed to find out that the design does not support it and that the code is practically unreadable. Will the Development Lead take responsibility for her decision to waive Design and Code Reviews? Probably not. Most chances are that the developer will be blamed for writing such poor quality code.

*** 

Accountability is the keyword in this discussion. We abuse the term “Good Enough Quality” on a daily basis and use it to avoid our responsibilities. If this is done after thorough consideration and analysis – so be it. You must consider all the relevant factors, however, and take into account that the customer is not the sole stakeholder of the Quality aspect, but that’s for another discussion. In any case, a few things have to be done to formalize such a decision.

First, someone should take responsibility for this decision. If the customer will raise some claims regarding the quality of the product in the future, someone apart from the developer should be accountable. In order for that to happen, the decision to go for the “good enough” strategy should take the form of explicit figures and guidelines: what will be considered “good enough” for this project. This is a good basis for negotiations (either internal or external). If no one agrees to take responsibility for the figures, you might need more resources or more time to develop the product. That’s how things work in the real world: in most cases, you can’t have both.

Without translating the abstract term “Good Enough Quality” into real-world terms, you create confusion and fuzziness. The customer expects one thing, while your developers understand a different thing. Without a clear definition, no one can take responsibility for the quality of the product, so when something gets wrong all that’s left to be done is calling the developer and demanding an emergency fix, leaving both the developer and the customer frustrated for a good reason.