Is Quality Negotiable?

Inclined to agree that quality is not absolute, and must be negotiated before it can be understood. For instance, if you look at code coverage as one potential measure of quality, it's exceptionally difficult to cover all code completely by all coverage measures. Accepting that one almost never has time to completely test code is a good start to accepting that quality is negotiated.

That said, there are some good examples in this thread about some examples of a quality standard that might not be acceptable. If you feel your customer's desired quality level endangers the project in other ways, then you should make that clear, and then, if necessary, walk away.

On the other hand, quality is often negotiable to a reasonable rate, and customers are often willing to listen to concerns about quality levels, when there aren't overriding business concerns.

In the situation described:

They are willing to rewrite completely the application few months after the release if they really have too. This is definitely not a problem of development cost at all (they can loose millions by not releasing the day of the deadline).

I maintain that it is very dangerous to take this statement at face value. This cannot be the start of a conversation.

First, you must back up one step, or maybe more. The term "quality" is loaded - and in the customer/user world, may be loaded in a completely different way than in the developer world! (As exemplified in the Cockburn story, above)

We need to learn a new kneejerk reaction to this: "What do you mean by that?"

Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!" Hmmm, is that what dev thought when they heard the statement, at first? :-)

deb

Quality means costs and risks that grow geometrically when deferred.

> "I don't care how elegant the solution is, but it needs to work!"
This could be also my first reaction to the client request: non-working code is just wasting resources, so one thing we could sacrifice, I guess, would be refactoring.

However, my experience is that:

-velocity goes down quite fast when refactoring is not done regularly
-it is very dangerous in the game of expectations, because the "[we will] rewrite completely the application few months after the release if [we] have to" is often forgotten after the first success (but of course, without that first success there is sometimes no second chance)

Anyway, even if we try to negociate quality, this is a real challenge to fix precise criteria upfront:

-how do we know we've tested enough according to the "Quality threshold"?
-how do we know we have a maintainable enough system according to the "Quality threshold"?
-how do we know we have a usable enough system according to the "Quality threshold"?

Most of the time, and especially on projects with hard deadlines, the "Quality threshold" is very subjective I think. Does anyone has a successfull experience of negociated quality with tangible metrics?

Eric.

Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!" Hmmm, is that what dev thought when they heard the statement, at first?

Hmmm.... I always thought that one of the great things about Agile was that it gave the Customer more power - since *they* know the business then they make the priority decisions and what gets done first.

At the same time, we could go overboard. Shouldn't the developer's make development decisions? Gold-plating is something, and writing bug-free code that meets the individual's definition of quality code is something else.

Aren't we all professionals? Shouldn't we trust each other to do the best that we can. Developers shouldn't be dictating business decisions, but isn't the opposite also true?

All of this - it should go without saying - is within the context of a self-organizing team that communicates well and communicates via GOALS instead of individual steps.

However, it's the also responsibility of the development team to remind the business that each 'short-cut' is another charge to the Technical Debt credit card. If that debt isn't paid off at some point, hired goons will show up at your door, baseball bats in hand. It's the responsibility of the business to listen to the development team and allow them to pay down that debt after the deadline has passed.

While cutting corners can increase velocity over the shorter term in order to meet a deadline, long term velocity will suffer if Technical Debt isn't kept to a minimum.

Aren't we all professionals? Shouldn't we trust each other to do the best that we can. Developers shouldn't be dictating business decisions, but isn't the opposite also true?

To clarify:

> Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!"

The background: I believe their team had been trying to give them very comprehensive solutions to their needs, while blowing their target dates and delivering buggy code.

I'm a little surprised by some of the responses here. I would have thought that most would understand that quality is definitely negotiable.

I think we all understand, even if it's just in our hindbrain, that we can't test everything, even those of us doing TDD. Testing everything is a good way to turn a $50 product into a $500 dollar version.

So, if we understand that we're already compromising, can't we also accept the possibility that our current understanding of what's "enough" may be too much? If there are different grades of steel for different uses, is it possible to have different grades of software?

If you don't think so, all you have to do is take a look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope. Most publishers will opt to release a buggy game and patch it later without much thought. Sure, this results in buggy games but it's also not unusual for those games to go on to become financial hits.

If you don't think so, all you have to do is take a look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope.

i think its a great idea, you can even go further - you can say - we can deliever product on time, but we wont have enough time to test it, so we wont be responsible for possible bugs. Then customer has choice and if he doest care about quality why force him? Of cause the best idea will be to educate him, but i think that many of them know how it all works.

I have never seen a customer who was willing to pay to get the quality up. It's always "10 to 20% of our needs working and a way to put bugs into change control with low cost resources to fix it after the initial project".

I imagine it is hard to understand why the software is built buggy in the first place, looking at it from the business point of view. It's just like building a house right?

I couldn't speak for southern Europe but I have had the same type of customer...

Part of the problem is related in our relationships to customers and an Us vs. Them relationship. The answer is touchy-feely, and very related to communication, personal responsibility, and clarity of the goals.

These issues are hard in any/all cultures and - I would venture to suggest - these points are applicable in multiple cultures.

You might want to check out Teamwork is an Individual Skill.

The other three points are cost, speed-to-market, and scope. We are not magic. An increase in any one of these areas needs to have a corresponding decrease in another. You can't increase quality without impacting either cost, speed-to-market, or scope. This needs to be negotiated with the customer at the start of every project, and every time any one of these factors changes, the discussion needs to be had again.
As for the implementation of Quality, you go back to the requirements determination phase, and implement non-functional requirements, which may be in the areas of usability, reliability, performance, security, safety, or supportability. It's the lack of these "Non-Functional" requirements that leads people to say "that product has low quality." It's simple to implement non-functional requirements, you can say for example "it is a requirement of this system that any the downtime is less than five minutes per month." You say that at requirements determination stage, *before* design starts, and the system gets built that way. Of course it's not cheap, and there is a corresponding increase in either cost, speed-to-market, or reduction in scope. And the customer must be negotiated with and agree. If they don't want the extra, they don't pay for it, they get the product faster, the scope does not budge upwards, and they get their "user-defined" level of quality.

Quality can be negotiated, but it should be discussed with the customer where they want to reduce the quality.
So where they want to reduce the time?
In design,requirenment , testing or coding.

In software quality is not just one line.It is applied at various levels in different way.

Further to
> It's just like building a house right?

"The Software / Construction Analogy is Broken"

> If they don't want the extra, they don't pay for it,
> they get the product faster, the scope does not budge
> upwards, and they get their "user-defined" level of
> quality.

And your software contracting company gets nasty blog press, don't forget about that!

Well, there may be a difference between "economy" quality and irresponsible quality. I admit it's difficult but I believe it is possible to set an appropriate level of quality that may be lower than what we would normally seek and yet deliver a product that satisfies the customer, the market, and ourselves.

If the customer pushes to dial quality into the irresponsible range, then the only thing we can do is push back or walk.

Sure, they can do that with WoW now, since they essentially have their walking skeleton in place.

However, if you think back to launch day, how was it? :)

Yep. There is a level below a minimum scope where value becomes zero. This is similar to a Minimum Marketable Feature (MMF) in Naked Planning .

It's a good (though completely illogical) rule of thumb that the exact same piece of software as deployed successfully will have bugs if it wasn't tested. My experience at least seems to match this rule. :-)

Is this Shroedinger's Code?

> Well, there may be a difference between
> "economy" quality and irresponsible quality.

I'd counter with this: There is also a difference between "responsible quality" and gilding the hammer.

The way to navigate between these two extremes is frank discussion with customers about their needs and the risks we perceive.

And, yes, sometimes it's time to walk. After you've discussed, of course, so everyone is aware of what happened.

PS: I'm astonished - Google has finally failed me. I wanted to include a web definition of "gilding the hammer" but...

look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope... Sure, this results in buggy games

Who's going to write the app that will let us send out credit-card statements to management for their accumulated technical debt? With a Jira-compatible interface or something.

Call it "FemaCard" maybe? ;-> or the MasterCanary card?

Ok, I'm probably the guilty party since I wrote the post, but.... Are we over-analyzing the problem?

It seems to me that this is really a question of communication of goals or tasks.

If we communicate through goals, then we can have a scenario similar to Dave Rooney's comments above:

I do agree, though, that teams with good communication handle these issue quickly and efficiently. On a coaching gig about 18 months ago, I was working with a developer trying to bring a part of an application under test. He wondered out loud why a certain small feature was needed, and if corners could be cut by not implementing it. I said that it sounded like a question that needed to be asked of the Customer who, by virtue of this being a Whole Team in One Room, was a few metres away. Her answer was that the feature would allow (the product) to compete directly with (a product from a competitor recognized globally). In less than 2 minutes, the developer had a perfect understanding of the business value and why he had to do something.

Hey folks. I have a question. It's unusual that a thread goes on for so many days (but fun!).

We hope to get a way to provide notification for "watched" comment threads, but for now it's entirely manual. So can you tell me:

How did you follow this thread? Did you go back and reread it manually to follow the conversation? Just interested from an editorial point of view. Feedback is always good.

Thanks
deb