Monday, May 19, 2008

Quality doesn't suck

I disagree with this post written by my friend regarding quality. This is my response - maybe not direct and not to all objections but still valuable ;)

- Quality? - all right, but if time permits...

How often do you hear that? If you hear that often it means that probably your product's quality sucks.

Suppose that your team has to implement some stories in the fixed period of time (let's also suppose you are not using Scrum and you are not iteration-oriented). Then the customer pushes the higher management to move the deadline - of course for the earlier date. Team lead will not throw away any stories (what she should do) because the higher management would fire her. What she will do? Tell the developers to implement the same amount of features in shorter time. Developers subsequently will also have to sacrifice something - most probably they will not sacrifice their family life and free weekends. They will sacrifice QUALITY.

According to "Peopleware" book your product requires much higher quality than your customers need. Why? Because Quality, far beyond that required by the end user, is a means to higher productivity.

Reading the same book further there is an excellent example. I will try to rephrase it here. If you think of high quality (either company, nation, culture, etc.), what pops to your mind in the first place? For me it would be Japan. Again, if you think of high productivity (either company, nation, culture, etc.), what pops to your mind in the first place? Japan? This phenomenon can be explained this way:

The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

But this post complains that there is no need to think on the design, architecture, etc. for too long - just do it. Yes - you're right. That's the XP idea of simplicity - design what you need today - tomorrow you will refactor your code, design and architecture, but if only you will need to do it.

That's the quality for me. More so if you utilize Scrum framework and follow XP guidelines you incorporate relevant (i.e. high) quality into your estimates. And there is no way higher management could impose the team to deliver the product faster with the same set of features. Your team velocity does not lie - you will not deliver more user stories because the number of story points is too big. The team can deliver the product faster but they will implement less features.

Agile development somehow imposes on you high quality (but if you are agile it doesn't automagically ensure that your product's quality is high). More so agile teams show to be more productive than "waterfall-like" ones. And here we meet high quality with high productivity. What you think about this version of the original quotation?

The trade-off between price and quality does not exist in Agile Development. Rather, the idea that high quality brings on cost reduction is widely accepted.

2 comments:

Nemanja said...

"If you can't do it right now, when will you have time to do it again?"

blog.konem.net

Fabio Nascimento said...

I know that story, this is called technical debit.
It is cheaper invest in quality.
It is more expensive invest in maintenance.