As a fast-moving, entrepreneurial organization we are naturally shy of bureaucratic process and the inevitable paperwork burden that comes with it. Our company has a strong engineering focus driven largely by customer demand. We prize our agility and are acutely aware of the need for new processes to enhance our workflow and not act against it. Three years ago we undertook our first ISO 9001 annual audit. I must say it was painful. You could feel the ‘I don’t have time for this stuff’ vibe emanating from just about every corner of the organization. As we embarked on the necessary journey into larger corporate process, this was clearly weighing on minds – particularly in the engineering dept.
Because the ISO 9000 family of quality management standards has been deliberately framed in broad terms to be applicable to a wide gamut of businesses, on first inspection ISO 9001 appears dangerously fuzzy to software engineers, who spend most of their day in the land of hard logic. There is a feeling that a prescriptive ‘quality manual’ misses the point.
Part of the problem stems from the absence of any formal definition of what we really mean when we use the word ‘quality’. Is it a property of a system or object that is directly measurable, or is it a more subjective beast – something that exists only in the perception of the individual? The more one thinks about it the more mercurial the concept becomes. It’s true that a large group of observers can usually agree on quality when they see it, but it’s generally hard for anyone to express why they perceive quality in something. In its general sense, it’s certainly not something that can be measured by any instrument. Yes we can measure properties that point to quality (feel the weight of the cloth) but not the stuff itself.
Quality is like intelligence: it comes in many different flavours. It is this multi-faceted nature that makes it so hard to grapple with. To an engineer, quality might be expressed in purity of function. A system or object that performs some function should comprise the minimum component set – as simple as possible, but no simpler. To a user of that system, who knows nothing of its internal workings, quality may be more about predictable and intuitive behavior. By intuitive I mean that the user can make use of the system without reference to manuals or formal training.
So the engineer sees quality as beauty in the internals of components and their functional relationships whereas the user is more concerned with usability, interface design and consistent behavior. Both of these aspects probably merit their own blog entries, so perhaps we will save those for future times, but there is a common thread here. Both these facets of quality – let’s call them internal quality and external quality – have a common consequence when present – they make people’s lives easier.
A well-engineered system is easier to maintain, easier to debug and gives peace of mind to users and support staff alike. An engineer looking at a well designed system for the first time or after a long spell of absence will find clarity of purpose in the individual components and their relationships. A well-designed user interface is pleasant for the user to work with and reassuring too. A new user of such a system will be quickly productive.
So let’s consider some characteristics that give rise high perceived quality:
- Well defined bounds on function – externally the use case should be clear. Internally the component functions well defined.
- A minimalist design approach – externally the purpose and operation of the system should be readily intelligible to the uninitiated. Internally the system should comprise a number of modules, the function of each and the interaction between them being clearly understood.
- Testability – if a system or sub component is not readily testable then we can have no certainty that it behaves as we expect. The corollary of this is that effective monitoring is only possible if systems have been designed to be testable.
- Instrumentation – this in the engineer’s window into what is going on. You should be able to monitor how users interact with the system in order to inform UI improvement as well as what is going on internally.
- Documentation – good documentation should follow the same principles of simplicity and minimalism alluded to above. Language should be clear, structured and precise. Words that do not actively contribute to meaning should be eliminated. Flowery, grandiose language which panders to the ego of the author has no place here. Structure should follow a hierarchy that is useful to the intended audience, flowing from the general to the specific.
- Incorporation of knowledge gained from previous failure. Volkswagen famously set new standards of reliability with the Beetle by continuously driving test cars around a track until parts broke and then using knowledge gained from the failure to re-engineer the parts in question. There is a lesson to be learned here. Continuous improvement goes very much to the core of ISO 9001.
And now to some enemies of quality. Aside from the omission of any of the above, a system that starts out shiny and pure, well-defined and immaculately executed in its first embodiment, can easily be turned into a complete pig by one of the following:
- Function fit – isn’t it tempting to loosen that small screw with a chisel when you can’t find the right screwdriver? But chisels are soft and screwdrivers are hard for very good reason. If the old sub system does not fit the new need, don’t use it.
- Feature bloat – adding four hundred programs to your top of the range microwave and linking it to your smart TV is bound to get some PR in some sad publication, but is likely to have a detrimental impact on core function as resources are diverted to the bells and whistles brigade and unexpected interactions creep in. Unfortunately many companies that pride themselves on tailoring their solutions to customers’ needs find themselves in precisely this boat.
- Cost-cutting – Born of a relentless drive for short term profits this is a dangerous mindset. Designing a solution to be low cost is entirely sensible. Attempting to lower the cost after design is often where the problems start and may finally result in elevated costs overall.
Once one of these paths begins to be trodden, it becomes very difficult to retreat. What seemed like an innocent quick fix becomes incorporated into the fabric of a larger system and weakens the whole edifice. One fix leads to another. The effort and time required for proper feature extension on a secure foundation grows and grows. There is increasing temptation to ‘put more lipstick on the pig’– the problem is, underneath it all, it’s still a pig.
None of this is exactly rocket science. It’s really more like common sense. ISO9000 can’t define quality. Nor can it provide you with a manual telling what to do to achieve it. But it can make you think, and the result of this thought process is to generate buy-in where previously there was none. Only by sowing this seed in the collective mind of the organization can true quality flourish. The annual audit just helps direct the fertilizer.