Quality

At my work, we make heavy use of a quality system in order to create software. The reasons for this are many, but they include the need to prove to customers that we produce software that conforms to certain standards. Another reason is the need to accurately manage the production of the software.

The quality system that we employ has certain problems though and this morning we had a brief meeting to explore some of the system’s demons.
The idea that the system is called a ‘quality assurance’ system has always grated with me a little since it does nothing of the sort. The system is perfectly capable of producing bad software with all the right ticks in all the right boxes. I’m not saying that we produce bad software - I’m just saying that the quality system has an inappropriate name. Luckily the people who work at the company are quite capable of producing a good software package of their own accord.

All that the quality system does is prove that we can follow processes. That’s it. It’s up to the processes to be good to end up with good software. Or that’s the theory, anyway.

The meeting this morning was welcomed because it became apparent that the company does not wish a ‘conformance to procedures assurance’ system. Why should it? It’s not good for business to have your staff wasting time on procedures that add no quality to the finished product. The company does wish to have a system that produces quality. This makes sense - a company with a quality product that meets all the elusive attributes of ‘goodness’ will do well. People will want to buy stuff with a high level of quality.

I’m glad this revalation was brought to the attention of the staff because it’s hard to maintain motivation serving a quality system that adds little of value. A computer programmer wants to program computers. A computer programmer doesn’t want to do a little bit of programming and then spend the rest of the time creating documents that pretend to prove that the programming was done well.

All of this prompted an email debate with some colleagues about how the quality system should be redesigned to promote quality. It transpired that the book ‘Zen and the art of motorcycle maintenance’ had recently been read by myself and another, and so it became the centre of the conversation.

The meeting placed the maintenance of the quality system firmly in the hands of the staff, so it got me thinking about how to approach the design of a process that produces good software. The book talks about many ideas, one of which is that quality emerges from a love of what you are doing. Luckily I like programming computers so it seems that the current system is being detrimental to my motivation to produce good software.

Once you sit down and think about it though, it’s pretty difficult. How do you define how to produce good software? Good quality software is recognisable though. People who use software would be able to sort the software they use every day into ‘good’ and ‘bad’ with no problem. Everyone, therefore, knows what good quality software is. But how do you explain what should go into software to make it good?

Good software is many things. It performs its task well. It is intuitive to use. It has good manuals that explain things to the user in an accessible way. It does not alienate the user. Good software serves the company that makes it well. It’s saleable, meaning more opportunity to create good software. Good software is lots of other things too.

Above all, it’s ‘good’. A software-quality assurance system therefore, should not explain how to create good software. A software-quality assurance system should explain the environment in which good software tends to arise.

If we all loved our jobs, there would be no need for false, estimated, pointless schedules to drive people onwards to fictional deadlines to make sure the job gets done. There would be no need because we would produce the software out of a love for what we were doing. A QA system, therefore should exist to create an environment that makes the people who work on the product love what they are doing.

I may be being naive, but I don’t think that’s as impossible, or ridiculous as it sounds.

Someone suggested that the entire quality system should be replaced by a single piece of paper that just reads “Make beautiful things”. It would apply to all departments. Good quality software is beautiful. Good quality manuals are beautiful. A chart on an accountant’s desk where all the numbers add up perfectly is beautiful. Software that installs and uninstalls cleanly is beautiful. We all know the difference between something beautiful and something ugly, and we all pretty much agree. What else would be needed? Nothing could possibly be produced from such a system but something beautiful. Something with quality.

That’s an end to the rambling, disjointed thoughts. How would you, dear reader, create a system that promotes such an environment? There’s a place in the history books up for grabs to the provider of the correct answer.

Add comment March 23rd, 2004