Quality is a feature, not a constant

I can hear you objecting already! Quality, says the Agile handbook, is non-negotiable. If you want feature X, then you have to have it with 100% quality as determined by the developers. No user/customer is allowed to say “Oh I want features x AND y this iteration.. and I know you can’t do them properly but I’m sure you can think up some quick fix”. What they are asking for is a hack. And we don’t do hacks, do we? So the response is to say.. well you can have feature x1 and y1 this month which is half the work and features x2 and y2 next month, which will complete the other half.

That is not the sort of quality I’m talking about.

The sort of thing I’m talking about is application quality not about code quality. So the user can ask for things like “the server can never be down for more than 5 minutes in a year”. This kind of user story is a type called a constraint story, which is different from the usual feature-led type. This is an odd kind of user story as even though is has the user experience at its core, it still knows about “the system”, which is generally not the way user stories work. In any case, this story will clearly require work, so it will need to becosted and included in an iteration at some time. Although we might prefer to put this kind of story near the end, if the constraint story was “The server must never lose an order request” then we might want to know about that up front. In fact, given the word never we might want to start looking for another job!

In any case, that kind of request is not only a feature it is a very expensive feature. To get something like “..never lose..” working you will not only need to implement some serious enterprise code but you will need some serious test capability that will go way beyond what you can get out of unit testing (although, of course, unit testing will provide the “atomic” tests and give the safety net to refactor towards this incredible reliability). So this is a lot of work. In fact, I would go so far as to say that this kind of unconstrained constraint story will provide a near infinite 😉 amount of work. It will be difficult to time-box the work because until you can break it you can’t know the limits and when was the last time you broke SQL server?

So lesson #1 is don’t accept constraint stories that don’t have some sort of limit, even if they are crazy  (like the system will not lose more than one order in 100 million).

The other interesting thing is, where is this quality coming from? Clearly, this kind of “enterprise” strength quality won’t come from having a full set of unit tests. Although that might be necessary it is not sufficient. Code quality will provide the basis for refactoring towards our mega-reliable, ultimately scaleable solution but it won’t do it alone. However, can those building blocks of those “enterprise” applications be developed in an agile way? I’m not sure, but it worked for Linux. I know, it is a special type of programming and you wouldn’t expect a electrical engineer who can build a power grid for a country to be able to design an audio amplifier for a TV, but I can’t even see where to start when it comes to things like creating an middleware application like MSMQ or SQL server. Still a long way to go before I get that journeyman badge. Sigh.

2 thoughts on “Quality is a feature, not a constant”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s