Demand Quality: You Get What You Ask For

“In the long run, men hit only what they aim at. Therefore, though they should fail immediately, they had better aim at something high.” – Henry David Thoreau

I recently had occassion to phone Sky because my ‘set-top box’ was misbehaving. While I was waiting in the queue for an operator, I was entertained by the requisite generic music, which was interrupted every 15 seconds or so in order that I may be given some useful piece of information about Sky or their services. One such interruption provided the following illumination: “Your set-top box is like a computer and so will need to be rebooted from time to time.”

I believe that this message crystalises the expectation that most people have of software; it is unreliable, mystical, needs manual support and is generally unsatisfactory.

On the other hand, Casual Miracles has recently completed an eleven month piece of work in a large investment bank. One of the reasons that we were asked to take part in this project was to ‘get it started’ since the incumbent team had been unable to do so for four months. Another reason was that the organisation has trouble producing high quality software. Business users are frequently dissatisfied with work done for them and a significant support team is usually required. Nine months after we started, the software was put into production. In the four months since that release the users have expressed pleasure with the software, no bugs have been reported and the support team have not had a single event to deal with. The only reason it has not been available continuously is that it has been taken down for new releases.

While the first story is an indication of expectations held by the general population about software, the second is a story of possibility. Keep in mind that this is not a theoretical possibility; Casual Miracles achieves these kinds of results as a matter of course. They are actually not very hard to achieve. A small fraction of developers and teams actually seem to find it easier to achieve these results than the alternative low quality stuff that normally limps over the finishing line of a software development project.

In this article I am not going to talk about the mechanics of this achievement. Instead I want to talk about one essential precondition. That is, the expectation of quality.

As evinced by the first story above, expectation is astonishingly low with respect to the quality of software. Although projects often start with grand ambitions (the grandness of which is frequently to do with size rather than quality), this usually rapidly subordinates to getting *something* done under a mass of bad approaches to management, implementation, analysis, politics, resourcing, etc.

In order to correct this problem a line needs to be drawn in the sand. Expectations need to be raised and a clear goal set. A system that performs the functions required by the business is necessary, but usually not sufficient. There are infrequent cases for which a piece of software can be said to have attained an appropriate level of quality merely because it doesn’t crash too frequently and its bugs are suitably hidden from the user but such circumstances are few and far between and should not be the aspiration of most development efforts.

At the very least we need a sort of Hypocratic Oath of software development – ‘Above all, do no harm’. But a better expectation is that the software will do its work in ways that bring joy rather than pain to the users and other stakeholders (including those who developed it). It must do this without need for significant support staff (if the developers are nervous about supporting it, pay attention!). Planning to rely on support staff to handle the inevitable crashes, data integrity issues and other failures is woefully inadequate. The notion of bug triage is to be deplored.

However, along with the expectation of high quality comes a responsibility. It behooves ill of stakeholders, whatever their function, to expect one thing and then behave as if other things are more important. No man can serve two masters.

When Casual Miracles was asked to take part in the project described above, senior management specified a few things that should be achieved. First and most obvious, deliver the software in some reasonable time. Second, the project was a replacement for another system that had been in operation for almost two decades and the software that we were providing should be capable of being maintained for an equally long time. Third, help the incumbent team to adapt to our ‘new’ way of doing things if we could, but do not let this requirement cause the first two to be threatened; if it could not be achieved, let senior management know so that they could take necessary action.

These were clear, non-conflicting goals. When the third goal did prove too difficult, senior management did what they had promised, thus affirming their commitment to the first two goals. These actions helped us to deliver the result that we did.

One of the most significant distractions from a high quality software product is the notion that time is excessively constrained and that quality should be sacrificed. This apprehension is often caused and maintained by business analysts, project managers and developers, rather than users or other, more senior stakeholders. But poor quality work is future waste. The appropriate thing to do, as Deming showed so many years ago, is to find and eliminate the cause of inadequate quality. This may be achieved simply by having the stakeholders confirm that quality is the goal and making adjustments elsewhere as necessary. If change does not follow, retraining may be necessary. If there is still no change, then more radical approaches are needed.

In short, if the expectation is low, so too will be the result. If you want a better result, expect it and admonish all stakeholders to expect it also. Then act consistently with those expectations.