Thinking about Quality

I've been reading more in Coplien and Harrison's Organizational Patterns of Agile Software Development. It's such a wonderfully thoughtful book, it is refreshing actually to find a book that is thoughtful. It really concisely and comprehensively classifies and diagnoses the relationship between the psychological and rational parts of team software development, in a way that's quite evenhanded and unbiased. It's a treasure of good ideas.
One issue I was just thinking about, which they don't address that much, is how to handle the high volume of support escalations, consulting ,training, complex debugging that accompanies very complex, customizable enterprise applications. The authors correctly suggest that crises should not be allowed to become a way of life. Nonetheless, it is the nature of contemporary J2EE based technology that the deployments are so complex at many Fortune 500 companies, that making any piece of software useful is extremely hard, and requires a fair amount of advanced consultation to succeed no matter how theoretically perfect the code is, if only to pin the blame on the latest Weblogic service pack. This work has a durable reality to it, it's just not going away! So how do we handle this work without interrupting the developers ?
One approach is to teach support or the maintenance team to handle it. But how does the maintenance team work ? They are a team that is by definition issue rather than feature driven. It can appeal to a certain kind of person, who likes problem solving, and it can be a good way of training people. But it doesn't fit well into the typical models. Clearly Steve Jobs has a point - make systems simple enough that they don't require a lot of fuss. It that sense the modern J2EE based multivendor messes may be architecturally the wrong thing precisely because they are so hard to understand and so maintenance needy. Yes, better software could help this.
Another way of looking at it, is to recognize the intersection between the customer support profession and the software engineering profession. It is interesting that few books on software engineering talk about support. Yet most nontrivial products require support, and the interaction between support and software engineering is one of the most important processes in the organization. These maintenance people are really straddling the worlds of software development and support. What we need is to build some process models connecting how programmers work with how support people work. Something to think about.

I've been listening to some interesting webinars from Rally Development with various prominent exponents of Agile Development. During Tom Poppendieck's talk he put up an interesting slide showing the taxonomy of testing in a good way.


In this chart the manual, exploratory testing goes in the upper right quadrant, where all the kinds of automated testing are classified in the other three. As is typical of agile thinking, it mostly worries about small systems with minimal integration requirements. I would put large scale integration testing, also under the category of "Customer Tests". The change is that the customer wants to make sure that the whole system works, not just the little component the current team is working on. These tests have to ensure that everything works when this piece is added or improved.
In this chart, the lower left quadrant, the unit tests are the province of the developers. The property tests mostly of the performance team. The customer tests are interesting. Pure XP'ers think the customer should write those. That's ridiculous in our world where the customer is nowhere to be seen, as is only represented in proxy by program management. This is really where QA comes in building test plans that reflect the realistic examples of how the system would be used, and turning those into practical automation.

The natural tendency of engineers is to make stuff more and more complicated. As organizations grow there is more and more communication between more and more people about more and more things. The more complexity we add, and the more communication we need to do, means soon we are drowning in emails and meetings and procedures. Where does it all end ? There's a simple tool for keeping our life under control. Ask yourself: If you do X, how will your behavior change ? If an action causes no one to alter their behavior, then that action is superfluous and does not need to be performed at all.
This is a wonderful simplifier. Don't "me too" an email if your approval won't really add anything. If no one reads a status report, don't produce it. It's amazing how much corporate bureaucracy can be destroyed this way. It also means that many of the processes we use become much more tolerable if we always interpret any of their requirements in these terms. So design documents should be written exactly to the extent that they communicate something of value to a defined audience, and no more than that. A lot of the criticism leveled against many allegedly "heavyweight" processes comes from ignoring this rule. If rigorously applied, may formal methods actually become quite simple.
Try it!

For most programmers, programming is a process, not a destination. That's why they hate to be pinned down to a particular completion date. Much of the tension in software development comes from the conflict between the amorphous nature of the developer's work butting up against external business constraints such as a commitment to ship something to meet a contractual date or before the end of the quarter. An argument made against formal software engineering methods is that by imposing a great need to have very accurate schedule estimates they discourage risk taking, because innovative risky projects involve too much schedule uncertainty.
There are two strong arguments against this. First, dates have a psychological value. If you know you have to do something by a certain date it will really focus you to get off your behind and do it by that date. I've worked on a very complex performance test where we had six months to make our product go 100 times faster than it ever had before. Until three weeks before the end we had no idea at all if or how we would succeed. But we did succeed. Interestingly, the customer had demanded from us a milestone schedule to show we were making progress. Given our lack of clarity how we could have provided this, let alone met it ? In fact we modeled our problem as a general process of investigation, with successive steps of analysis and experimentation. By avoiding clear commitments as to how much of the problem we had solved, as opposed to how much of it we understood, we actually created a set of milestones that we stuck to, exactly! Our success here came from two points. First, as noted, the psychology of the fixed date really concentrated our thinking. We had to succeed, and so we did. Second, we built our lack of knowledge into the schedule, choosing process rather than result oriented milestones, and giving ourselves a reasonable amount of time with enough buffer to handle the issues we didn't grasp at the beginning. In the end, our estimates were completely successful.
The moral is, you can build very accurate schedules of totally experimental things if you put your mind to it. Never confuse good process with the lameness of the bureaucratic mind!

The CMMI model provides a lot of ideas about many aspects of software development. Yet curiously it completely neglects certain others. However, CMMI itself provides a template for how to correct such omissions. For example, I realized some time ago that the key to successful recruiting was to make it an organized process. This organized process can be easily modeled in terms of CMM's generic process, and improvement measured in terms of the CMM levels. We can therefore invent our own "Recruitment Process Area" and study it in terms of defined processes, quantified, and optimized processes.
In that respect CMMI can be applied to many topics beyond those already covered, by using it as a template to describe how we can formalized and improve any organized area of human endeavor.

Process improvement faces many challenges. If you simply impose new processes top down, they will often be resented, and quickly ignored by the rank and file who simply revert to their previous ways as soon as no one is looking. The way to get around this is to involve as many people as possible in the decision making process, and build a firm consensus around each process. This way people will feel like it's their process and go for it.
Of course there's a problem with this. Engineers love engineering things. Building cool features is what engineers live for, and so programs over time sprout more and more features, just because it's a neat thing to do. Now, when you get those same engineers thinking about processes, they will soon make those processes really perfect, designing every little nuance until all cases are covered. Unfortunately this is a recipe for disaster. Humans aren't computers, and overengineered processes will quickly be ignored as being too hard to follow. In fact at all costs we should our processes very minimal. We should specify the least possible amount to get the job done, and resist all temptation at embellishment. This means fighting the deepest instincts of many of the technical staff.
Even if you can build a consensus around a nice simple process, the next challenge is keeping it simple. A particularly pernicious problem comes in if there are a couple of people in the community who for lack of understanding, training or ability are unable to do their work properly. A grave mistake is to solve this problem by adding more processes. Well designed, minimal processes assume competent, effective staff. Spelling out details that a normal good engineer can figure out without even thinking needlessly encumbers the processes. In fact personnel problems should be attacked through personnel means, not process means. Educate and train staff and replace underperformers, but keep the processes simple!

Is the goal of zero defect software possible ? How can you tell if you've tested something enough ? Obviously if you didn't work carefully enough there are likely to be too many defects remaining in it. Should you spend more time at it ? Could you eliminate all the problems ?
In fact, if you methodically enumerate use cases, and create definitive test cases for them, you can always state with confidence that as long as you confine yourself to the identified use cases, the product works perfectly. This is exactly why enormous pieces of software like the fly by wire systems used in airliners work perfectly, and without defects. Their use cases are exactly known, and flight crews are trained in the precise use of the software. They are diligently schooled NEVER to deviate from the prescribed procedures. In this case, as long as one methodically creates tests based on the known use cases, it is possible to produce software that works perfectly.
However, in other fields like enterprise software it is very difficult to enumerate all the use cases, and users are free to, indeed in many cases even encouraged to, invent new use cases. In this case you can only make probabilistic statements. Certainly as a product matures, it's total plausible set of use cases asymptotically approaches some limit, and indeed it is possible to have a state with very few defects. But prior to that point the very uncertainty of the problem always places an upper bound on what we can achieve.
In this world the difference between thorough and sloppy testing really revolves around how well the knowable use cases are discovered and tested. But even if these are covered very thoroughly, one should never have the hubris to assume it always work perfectly.
Still, the zero defect principle is a good one, because it asserts that by careful inspection and tool based verification one can make sure that a piece of software works perfectly within some specified realm. Taking this approach both to the software as well as the specification of the realm allows one to create the best possible approximation of zero-defect software.

To answer this question, we need to step back a moment, and look at the natural evolution of test strategies in organizations, and see where we fall in this pattern. In surveying the QA literature we find there are four main schools of testing, which have a certain evolutionary relationship:

(Note that I am omitting unit testing/test driven development here, but that’s another day’s story!)

Naïve testing is the typical initial process in many organizations. It is marked by informal test planning, unorganized manual testing, little knowledge by QA as to exactly how the system works, and relatively unpredictable results. In particular, it is highly dependent on the skills and initiative of particular testers, with some doing much better than others. In practice it is often manifested by a tendency to file lots of trivial UI bugs, while ignoring the trickier parts of the system.

On this foundation the introduction of formal test planning marked a revolutionary step forward. The general idea is that we enumerate the capabilities of the system, and for each capability we enumerate exactly how one can minimally verify that that capability works. The result is a series of test plans that precisely classify the system’s capabilities, and provide a list of specific steps for verifying those test plans. A common way to implement this is by using TestDirector as a central repository of such test plans, and of the test results following from the execution of those plans. This scheme introduces huge benefits. First, it forces everyone to identify exactly what needs to be covered by testing. It thus far broadens the scope of testing from the relatively random coverage found in naïve testing. Second, it makes the schedule of testing very predictable, in that if one has correctly enumerated the capabilities of the system, and has a good set of test cases, the regularly scheduled execution of those test cases will exactly verify the working of the system. It thus makes QA a precisely schedulable activity. I term this approach scripted testing.

The approach is not without weaknesses, however. The most obvious weakness is that for a large system the set of test cases becomes immensely tedious to execute, requiring huge amounts of time and labor. Because of its time consuming nature, individual test cases cannot be run very often, meaning longer feedback cycles for developers. The obvious improvement on scripted testing is to automate as many of the tests as practical. Then they can be run every day. This has several large benefits. First, regressions introduced by code changes are caught very fast, and secondly, platform certification becomes very easy.

Yet there is more to the story. There is a fundamental objection to the entire concept of scripted testing. The basic premise behind scripted testing is that one can enumerate the capabilities of the system. In truth, for most real pieces of software, it’s almost impossible to do this completely! As a result any set of test plans is an approximation of the true scope of the application. In practice many large systems are relatively incompletely specified with only fairly intuitively understood semantics. As a result, if we only test what is in the documented test cases, we must necessarily fall short of correctly testing the product! What’s more, once a new piece of code is made to pass the known tests, the actual probability of having a regression is actually quite low given the huge scale of the code. As a result overtime the scripted/automated tests tend to find less and less real problems.

This phenomenon results in the anomaly that even a module that has been QA’d according to the process can reveal many PIs if a skilled engineer once sits down with it. This anomaly is a very profound issue. In fact, psychologically most good QA engineers instinctively rebel against scripted testing for precisely the reason that just executing the test scripts doesn’t reveal the problems that they know are full well lurking in the product. The fact that our current scripted testing approach frowns on exploratory testing has a lot to do with the considerable unease the QA team has shown for the scripted testing system, (and by extension their misgivings about those who implemented the system!).

What’s going on here? In fact, in QA there is another theory of testing, called Exploratory Testing, that explains these matters. Exploratory testing starts from the premise that almost no real piece of software can be fully specified. (Note that this discussion tends to apply more to UI rich pieces, than purely server side components, which in many cases do have quite precise semantics!) . Where Scripted Testing believes that the test plan is the End of testing, Exploratory Testing states that the Test Plan is the Beginning of Testing. It says that once the scripted/automated tests have removed regressions from the system, intelligent, informed engineers have to use their judgment to probe the system, and use the known pattern of failures from the scripted testing to guide novel attacks on the system. This is really a kind of advanced manual testing, and practitioners of it have invented a variety of heuristics to make it effective.

In fact automated, scripted and exploratory testing play well together, because automated testing provides the QA engineers the time to do exploratory testing, and the results of the exploratory testing provide feedback that improves the scripted and automated tests. This is especially important for very high quality systems, where in many cases the only way to find new defects is by very hardcore manual testing. In these cases a full set of automated tests covering the 99.5% of the obviously known stuff, and manual testers to chase down the rest will produce the most perfect possible result.

One of the most interesting aspects of exploratory testing is that it is perfectly in accord with the psychology of good testers. To people who like to break systems and are good at it, this is intuitively the most satisfying approach.

The net result is that we find a balance between automated and exploratory manual testing.

Lets suppose you want to double the size of a team fairly quickly while not compromising the quality of the people you hire. How to do this ? I found in this instance that a very organized approach is helpful. First one needs to build full consensus about who you want to hire, and what attributes they should have. Getting everyone involved in the hiring process to agree on this is crucial. It's also helpful to define for different specific positions to be filled, exactly whom you want to have interview the candidates, and make sure there is some coordination on the kinds of questions asked. Now you can go ahead and start screening. There's no real need to use a recruiter; an account on hotjobs will do just fine. You need to make a discipline of every morning reading the resumes; build and save a good query for filtering them. Then call the likely prospects and phone screen them. If there's a lot to be processed, you can get a couple of people to do the phone screening. If they're good, bring'em in and start interviewing. An important trick is to train the team to make decisive answers. Thumbs up and thumbs down are good, thumbs across is annoying. Once you've run through some interviews, and have calibrated everyone's way of looking at the candidates, the team should become pretty good at deciding yes or no . As long as one keeps pumping new prospects into the system, you should get lots of hirable people out the other end. It's all about staying focused, having agreement on what to look for, and being real consistent.

This book is really useful for doing work with CMM. It provides a complete catalog of all the practices covered by CMM. What we did is we made up a spreadsheet based on the list in the book and then looked at all our activities in the light of that list. This was very productive because it identified all kinds of areas where we could improve ourselves. What's neat about this book is that it's such a complete catalog of everything a sophisticated organization should be dealing with. For each activity you ask the same questions: are we doing enough ? Is this what we want to do ? Are we agreed on what we should do ? How can we improve it ? How can we measure our improvement ? We turned the resulting list into a set of action items for improving our organization. Then periodically we return to the list to see how we can enhance it.
While you can download the CMM 1.1 spec from the net, having it in a convenient handbook like this is great. We often wound up referring to it to get clarification on various points.

I find it too funny that almost all the Indian outsourcing companies are CMM level 5 certified. Yet what they do isn't particularly better than what anyone else does. I know what you're thinking - that CMM stuff is all worthless. But the confusion lies in the meaning of CMM and of certificates. Getting certified is a form of external validation, so that if I merely tell you that I do CMM, you might not believe me, but if some approved person validates that I do CMM, then you'll believe it.
That's fine for government contracts where you have to prove that you do CMM, but it's missing the point!
CMM is not a piece of paper. It's not a bunch of bureaucracy. If you have truly defined processes that reflect what YOU really do, and if you continually self-assess to make sure that the process is what you really want to do, that it's the best you can come up with, and if you use measurements to make sure you're on the right track, then you're doing CMM.
Remember: it's getting what you do aligned with what you say that counts!!!!! Certification should only be attempted if you actually need it for contractual purposes. Otherwise it's just a waste of time.

Is there a difference between offshore and local development ? None at all really. The biggest mistake many executives make is that they are so mesmerized by the promise of cost savings that they think that the normal laws of project management are somehow suspended by going offshore. This is the peak of foolishness. If it's a bad idea here, it's a bad idea there. If it's a good idea here it might be a good idea there.
In particular, we know that good communication is that makes the team work with good quality. Communication requires a shared language and good fidelity. If you hear the other person, but not understand them, then there's a problem. If you can't even hear them it's worse. All of us have noticed that if you split a team on opposite ends of a building, the team will function less well than if they are side by side. To have good communication requires proximity. Mostly proximity is physical. In today's connected world if people really related intellectually, you can use virtual, on-line proximity as a substitute. A shared language is also required. You really need to be able to comprehend one another.
Given these requirements, how does offshore development work ? It has two strokes against it to start: a language barrier and great distance. There are a couple of ways of attacking these problems. The simplest technique is simply to have an entire team offshore. In that case they're far away, but all together, so their communication is all local. This is really the easiest way to go, and the most scalable. It will require that you have some trusted managers there, and good communication with those managers. Alternatively, you can build the online, virtual community. This can be quite hard until one can grow mutual respect and cooperation. The language barrier tends to get overcome with time and practice, as everyone learns to talk to one another.
Another issue of course is the time barrier, if the remote developers are just at work when you're asleep. Here having a complete remote team helps, because they'll be more self-sufficient and you won't have to interact as much. Also a virtual community focused on email and such will work too. What you want to avoid is micromanaging the remote team by telephone. This will be draining in the extreme. You'll get too tired.
But if you just remember that development is development wherever it's done, and apply the same discipline of people, environment and processes, you will get the same quality result no matter where you do it.

While reading Slashdot I stumbled across a really great book, Organizational Patterns of Agile Software Development. It's available online too here.

The book is interesting on two levels. First, it's fascinating how they apply the theory of design patterns to software engineering management itself. Second, their systematization of agile development practicies is deeply thought out. It gives lots of food for thought for all of us!

The title of this entry is an age old maxim for everyday living. If you live this way people will always have an easy time dealing with you. If an organization lives this way it will have an easy time dealing with itself. Say what you do, do what you say is at the heart of all development processes. The first half, say what you do, encourages you to carefully reflect on what you do, make sure it's what you want to do, and then state that this is what you do. The second half, do what you say, implies that you are committed to your beliefs and actually practice them, perhaps even check that you practice them. And this is heart of process thinking: deciding to work a certain way, and then actually doing it.
This is why you should never believe anyone who tells you that processes need to be thick stacks of documentation. Maybe a process is only a sentence. The key thing is: it must correctly express what you want do, and you must go forth and do just that. Never say it if you don't mean it. And never say something you don't understand, or that doesn't reflect your behavior or thoughts. Or put another way, with processes, it's quality rather than quantity that counts.

Most software companies have a Quality Assurance Department. Does doing QA make for quality products ? Actually it's quite unlikely. The naive thought is that if we test enough, the products will become good enough. In fact as Microsoft shows by sheer brute force you can make things pretty good, but they'll still never come out right. It seems that the more one tests, the more problems there are. But why ?
The trouble of course is that all our expressions of our ideas, read - requirements - fall short of reality. What something does and is supposed to is always greater than the requirements. Any finite test of the system based on those requirements will always fall short, no matter how long you work. The problem with this way of thinking is it already assumes a low quality product, and uses testing as a way to compensate for it. Defeat is in fact built into the strategy. Is there any way out ?
Since we know that a quality process will produce quality work, what we really want to ensure is a quality process, more than quality work. If we redirect our QA efforts at testing the process, then the result is likely to of vastly higher quality. If we consistently ensure a high quality process, then we consistently have a high quality product as well. And quality is always easier to improve from a state of working than from a state of brokenness.
Our ideal really is to have a continuously high quality process such that only high quality products are built. Testing then consists in testing our ideas and our thinking and our discipline. If we can continually question our approach and make sure the approach is absolutely correct, then we are making progress!

All our processes are necessarily an approximation. They are the best we can make today. But our knowledge is always incomplete, and we therefore always need to learn more. If we learn more, we realize that what we're doing isn't quite right. Which leads to having to improve our processes.
We should never think of our processes as being static. The metrics we employ to assess our work should always suggest way of improving our processes. However simple intuition should never be neglected here either. If we keep our processes simple and minimal and non-bureaucratic and precisely minimally fitted to our current requirements, then our learning, quantitative and qualitative, should continually drive rethinking of our processes.
Of course circumstance and difficulty shouldn't immediately cause one to abandon one's processes. This is a descent into chaos. A process is only useful if it can meaningfully direct work. That is, if actions don't conform to the process, then the process helps by allowing the group to recognize that the actions are incorrect. This requires some will power and honesty. But the same will power and honesty must make one realize when the process is wrong and requires adjustment.
Therefore process is always a balance between application and improvement. Too rigid, and the process becomes either a bureaucratic hindrance or a bureaucratic irrelevancy; too flexible and the process dissolves into nothingness.
Finding that balance is why management is challenging.

All problems interesting enough to think about require a group of people to attack them. We've talked about the quality of people as mattering. What quality are we looking for ? We have quality people when we have a team of people working together in an effective way to create a quality solution. What do we need to accomplish this ? No matter what abilities people have natively, what counts for our purposes is that they are willing and able to apply those abilities to cooperatively solving our problem. The essence of a team is that the members of the team put aside their egos to selflessly work together on a common purpose. If they buy into the vision of the team then they will work for that vision as if it was for themselves. The common purpose defines the team. We will call this common purpose the vision.
This already implies one of the crucial issues in the Quality of Environment. A quality environment is one in which there is a defined vision that quality people are able to buy into. The vision is what enables the team. The team cannot create the vision. This is a key management lesson. A lack of vision will kill the best teams. It's only by keeping the vision alive that teams can even function.
With that vision in place, we need to select people who have the ability and the willingness to do the work required, and who are able to buy into the vision and cooperate at achieving it. All the processes we define are really social, group affairs. We will want our recruiting process to look at the intelligence and learning capabilities of candidates not only as individuals, but also in their ability to cooperate and collaborate as part of the team.
We previously isolated effective communication and listening to be crucial to the Quality Environment. We now see that having the right people makes all the difference here. If the people cannot or do not want to listen, then the Quality Environment is not achieved. The functioning of the team therefore depends on management creating an environment where listening is possible, which requires management itself to listen, and on then assembling a team that itself wants to listen.
We see then that a team requires a clear vision, a communicative environment, and the selection of people who can collaborate and communicate effectively in achieving this vision. We will later talk more about the recruiting and environmental processes that make these happen.

The Software Capability Maturity Model Integration (CMMI) from the Software Engineering Institute at Carnegie Melon University provides the conceptual basis for thinking about processes. Many people tend to misunderstand process as a formalistic, legalistic or bureaucratic concern. This is far from the truth.
The fundamental question all of us face in life is: do we do what we choose, or do we choose what we are doing ? Do you like that band because you like their music, or because MTV is showing their videos a lot ? Did you really listen ? It's a deep issue that affects every organization. If you do because of habit and not because of choice, you have lost of all control over your destiny. But since success is difficult, it is unlikely to be obtained unless you choose to be successful.
Process is about an organization gaining control over its destiny by exercising its ability to choose freedom. How does this work ? In the CMM model there are five basic stages.

1. The initial stage is where the organization does things out of habit and accident. In this stage productivity is accidental and therefore both unpredictable and unlikely.
2. In the managed stage the organization becomes aware of its habits and tries to engage in them in an orderly way. Whether or not its habits are any good, at least the company does the same way each time. This is the beginning of enlightenment. While results are predictable, they are still likely to be predictably bad. At least though there must be enough consciousness in this phase to consider the need to be consistent.
3. In the defined stage the company decides to do things because it wants to do them rather than because of habit. Note that what gets decided on does not need to be complex, it just needs to be what the team feels is appropriate. The key thing is to do what one decides is best, rather than what is the status quo. In this phase creativity and careful thought often leads to improvement. However, there are pitfalls. Many people want to impose their will and impose a consistent order on all cases, whether or not it fits. This must be resisted. The defined process must meet the particular need. It must be tailored to circumstances. Another problem is that while there may be many interesting ideas, many of which can win a consensus, this does not mean that there are necessarily many good ideas.
4. In the quantified stage the organization uses metrics to assess the quality of processes. Without metrics there is no systematic feedback. Without feedback there is no true communication, and one is dealing with fiction rather than truth. Metrics make the process real.
5. Finally in the optimizing phase metrics do not merely decorate powerpoint presentations but inform the organization's thinking and allow it to improve its processes.

The central idea here is that processes must reflect the organization's choices. It's not how many processes you have that matters, what matters is that your processes reflect your actions, and your actions reflect your processes.

Anyone contemplating process improvement should keep this in mind.

Quality in the whole can only come from quality in the parts; and the parts are interrelated.

Often people only ask about the quality of things. But if the process that produces the thing possesses no quality, then the thing will trivially contain no quality. But if the people who use that process possess no quality, then the quality of the process does not matter. People and process are intertwined, however, in the environment. The environment is the context of communication. It is the question if a person can say good and can say bad and be understood) either way. That means both physical communication (some one must hear), and true communication (someone must hear and listen). People work together and interact. If the environment does not encourage them to interact well, then process and work suffer. Really a set of people produce a product because the process allows them to, and because the environment does not disallow it.

We therefore have a simple hierarchy of quality. To ask, does this system have quality, we ask the following questions in exactly this order:

• Do we have quality people ?
• Is there a quality environment for the people to work in ?
• Do the people have quality processes ?
• Does the product have quality ?

Tackling these questions in the wrong order is logically incorrect, and can only lead to confusion. For example, if one has foolish people building something, asking about the processes will tend to produce foolish answers. Only once there are quality people, do we quality answers. Only with quality answers can ask about the quality of the processes, and so forth.

Quality appears primarily in relationship to things that are made. Things that are not made do not participate in the duality of quality and not-quality, and therefore transcend quality. A flower has an intrinsic perfection that made things lack, at least to the extent that they are made things. So quality as it is perceived is in relationship to how the thing possessing quality was made. But to be made implies that someone made it. We already talked about the quality of the process behind a thing. Yet since someone engaged in that process to produce the thing, we need to look beyond the quality of the process to the quality of the maker.
We therefore arrive at the three-fold definition of quality: the quality of people, the quality of processes, and the quality of product.
Note that the quality of people does not mean an intrinsic judgment about those people, but rather refers to the quality they bring to the process. This introduces the basic ethical dilemma of management, namely that we view people not as who they are, but as who they are in relation to the work being done. We are concerned about their quality as individuals and as a group, as a component of the total quality of the system.

Let's establish some context. How does quality fit into a business ?

A business is an enterprise where one party, the seller, identifies another party, the buyer, who has a need that the seller can and is willing to fill, which the buyer is willing and able to pay for, and where the amount the buyer is willing to pay is greater than what it costs the seller to fill the need. If we assume that the buyer and seller are correctly identified, the key issues are (1) to what extent the seller's product or service meets the buyer's need, and (2) the extent to which the seller can profitably provide that product or service.

We can define quality for a product then in terms of surpassing the expectations of the buyer and the seller. We surpass the buyer's expectations by delivering a product or service better than what they had hoped for. We surpass the seller's own expectations by delivering the product or service more cheaply than expected, thus increasing profit. That profit is determined by the process used to create the product or service.

Quality is therefore always a double edged proposition in business, referring both to the quality of the product and the quality of the process that creates it. We will find that product quality and process quality are always inextricably linked.

Best start where I did, and study Pirsig's Zen and the Art of Motorcycle Maintenance. It's not about motorcycles, but it does clearly dissect the history of western philosophy. Having done that it introduces a bridge between traditional philosophical vocabulary, and this great word quality.

We're going to spend some time with this word.

Pirsig uses Quality for the same concept as Heidegger's Sein (Being). It's an interesting usage. Heidegger in his essay on Vom Satz der Identitaet posits the distinction between quantitative and qualitative identity. Qualitative identity is not merely that one thing can replace another, it is that it exists as that other. What on earth does this have to do with our usual sense of quality ? Quality in the usual sense of how good an example something is of something. To wit, a quality automobile is a very good automobile. To embody quality is to be very completely and perfectly that which something is trying to be.

In that sense to possess quality is to really be something, as opposed to some fragment of shadow of something. In other words, something is of high quality if it is what is supposed to be in the first place. If some set of parts are combined to make something, if collectively they succeed in being that something, then they have quality. Any if they achieve that something completely and utterly, they become that something. A Porsche 911 is the pure expression of automobile; it has quality. Listening to Otto Klemperer conduct Beethoven is an experience of complete musical quality. This perception of perfection is an awareness of complete being in the world (Dasein).

Pirsig though uses Quality in a deeper sense, as does Heidegger, to mean appreciating the quality of the universe as such, the quality of the horizon beyond our mind. This wider sense of quality is important to us, because only in appreciating the edges of our horizon can we truly become aware of and in control of consciousness. This is why to create the quality of things the enlightened master must first conquer the quality of being itself. The need to make and remake this conquest points out that quality is an ongoing battle and not a steady state.