Spin zero

A curious experience yesterday: I accompanied a couple of colleagues to a meeting with a customer who wanted to complain about some software we’d delivered. There were too many defects in it, and though they’d been fixed since, they shouldn’t have been there in the first place. It was my job to explain, as the person responsible for Development, how this apparent failure of Quality Assurance could have arisen.

The secret to making a success of a meeting is in the preparation. That’s generally true enough, but it’s hard work, not something I try to do too much of unless it’s really necessary, and quite a lot of the hard work may be wasted anyway. E-mails or even phone conversations don’t always give you an accurate view of what a client’s concerns are, so you may well be forced to improvise pretty extensively once you get into the meeting and find out what you really need to be addressing.

In a general sense, however, I was well-prepared for yesterday: my task was justify the way I do my work, and that’s a subject I know better than any. So I just told them. I explained how many people we have in QA, how many we use from time to time from offshore, how many we have in documentation. I pointed out that if they told me that double that number would be a good thing, I would probably agree, because you can never do too much QA or write too much documentation – the more you do, the fewer the problems downstream and the less time other staff have to waste correcting them – but you have to balance that kind of effort with the general demands of work on products themselves. I told them that I was already taking 20% of the company’s revenue for Development and didn’t have the gall to ask for more (the standard in our sector is 10-11%). I showed them how we were changing the structure of our products to make defects less likely and easier to fix. And I pointed out that even with the most extensive QA, the ultimate test could only be carried out when we got onto a real system, with real volumes of data, and find the problems we couldn’t even guess at beforehand.

Finally I tried to demonstrate to them why I felt we were getting the balance about right, because although they’d had an unfortunate experience, generally defect rates were falling although we were delivering more and more complex products.

Interestingly, by the end they were nodding and agreeing, and the whole meeting lasted little over half the time allotted for it. They even agreed to our using their own test system for validation on real data at full scale in the future. So what I expected to be a tough meeting turned into a good one.

Afterwards, one of my colleagues said ‘I like the positioning you adopted.’ I was a little surprised. I wasn’t aware of having positioned anything. I’d just told things the way I saw them. His reaction was curious and pointed me towards an important general principle. The truth as you perceive it is sometimes the best thing to say: it’s the easiest position to prepare, because you know it already, and it comes across most convincingly.

I wonder whether we should call that ‘natural spin’?