Software Quality Requires Professionalism and Fortitude - ASQ

Software Quality Requires Professionalism and Fortitude


Download the Article (PDF, 56 KB)

Dave Miller

Software quality activities serve to monitor how software developers are following established processes, in order to minimize risk and ensure that plans are reasonably achievable. Software developers claim prerogatives as professionals, and techniques for managing professionals are useful tools for software quality engineers. On the other hand, challenges facing software quality engineers include developers’ disdain for process management, managers’ timidity in enforcing processes, and the nature of software development tasks. To ensure that the development organization operates predictably, there must also be discipline. The software quality staff must understand both how to lead by influence and how to enforce processes.

Key words: anthropology, control, discipline, ethics, morale, objectives, process, professionalism, quality, retention, software, teamwork, values


Software developers regard themselves as professionals, so it is useful for managers and software quality engineers to understand how to manipulate developers by treating them as professionals. It is also useful to understand the psychology, sociology, and even anthropology of software developers.

On the other hand, it is important to understand developers’ shortcomings as professionals, the nature of most development tasks, the weaknesses of some software managers, and the role of software quality engineers as enforcers of process. For many aspects of software engineering, it appears that performance is most predictable and of best quality where the work is controlled using defined processes. The main job of management and quality together is to ensure that development tasks are identified, assigned, scheduled, completed, and verified. Simply relying on developers’ professionalism may be counterproductive. Combining an atmosphere of professionalism with commitment to systematic management may have a higher probability of improving performance.


“Professionalism” is among the most overused words of today’s American vocabulary. There are “professionals” who are doctors and lawyers. Scientists and CPAs also regard themselves as professionals. So do professors. So do engineers. So do janitors and carpenters and secretaries. One manufacturer advertises its vehicles as “professional grade.” If the term “professional” merely means that there is money involved, then it is redundant. A professional is simply an employed person, and a professional truck is simply one that is available for purchase. The term professional has good connotations: people feel good about referring to themselves as professionals. But as commonly used, “professional” often lacks meaningful denotation.

What do software engineers mean when they call themselves professionals? Does it mean they are committed to learning and following best practices, devoting their energies to serving customer needs with passion and commitment, and adhering to a code of ethical conduct? Or does it mean they want to write code as they see fit, without providing metrics or conducting reviews, and that they should not be asked to follow processes or worry about schedules?

Quality consists of doing the right thing, and doing that thing in the right way. Software quality therefore consists of knowing what the right task is, knowing what the right schedule is, knowing what the customer’s needs are, and then making sure the software is developed and delivered through methods that provide the best chance to accomplish the goals. Anything that interferes with those methods is an impediment to software quality assurance. Goals do not get accomplished by accident, or by teams that do not work together effectively and predictably.

The quality industry generally assumes that best results are to be gained by top-down enforcement of standardization and process control. This is the basis for ISO 9000 and the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) certifications, which are required by some customers. Arguments for process discipline center on the assertion that defining and enforcing processes lead to better definition of requirements, improved efficiency and productivity, and overall success of the organization (Schmauch 1994; Dunn 1990; Humphrey 1995; Perry 1991). There appears to be considerable evidence that process discipline can lead to excellent results. As an example, Michael Fagan’s inspection methods have been shown to result in cheaper, faster, and better results (Fagan 2001). It is natural to expect software developers to know and follow such best practices.

But in the world of software development, such expectations usually lead to disappointment. Few developers have heard about CMM, personal software process (PSP), TSP, or cleanroom techniques. Of the developers who have heard of such methods, only a fraction will voluntarily use them.


How do you manage people who want to have their cake and eat it, too? Physicians, lawyers, and CPAs all have to pass rigorous examinations. They must refresh their knowledge through continuing education programs in order to remain accredited. Would you want a surgeon who refused to take board examinations or who refuses to adapt to generally accepted best current techniques? Or an internist who does not stay up to date on studies about the drugs he or she prescribes? Or a lawyer or a CPA who did not keep up to date with laws and practices? Most people would angrily file lawsuits if they were injured by such lackadaisical professionals.

From the frequency with which the term appears in the literature, it is apparent that software developers assume they should be regarded as professionals. But do they make the investments in education and certification that characterize professionals? Accreditations are available for most engineering disciplines, yet few engineers attempt to get certificates (Ford and Gibbs 1996). I don’t recall ever meeting a software developer who has received—or even tried to get—certification as a professional engineer. I once heard a software developer bemoan the fact that his home state requires passing an examination before one can have a job title containing the word “engineer.” It also appears fairly unusual for a developer to seek out regular refresher training. Few developers appear to read technical journals or new books about their fields. If you don’t believe my experience is typical, read SEI’s report on software professionalism (Ford and Gibbs 1996). Software engineers seldom pay any attention to professional codes of ethics. They are not required or expected to belong to professional societies.

Who enforces professionalism among software developers? If a developer screws up badly, what happens? Has anyone ever heard of an individual software developer being sued by a client because of an egregious mistake? Is there any independent review board, any formal warning process, or any mechanism to remove the developer’s privilege to practice development? There is no “software malpractice” for software engineers (Daughtrey 2002). (Times may be changing: I am told that some universities have begun offering classes in liability law as part of computer science curricula. Perhaps they should also teach about engineering ethics, personal responsibility, the history of accidents, and other aspects of software professionalism.)

Perhaps these differences between software developers and physicians and lawyers result from differences in expectations. Who expects developers to be professionals? What incentive is there for management to treat software developers as professionals? Do software development tasks typically require the high level of independence and sophistication characteristic of professionalism?


Are software jobs conducive to professionalism? When one needs triple-bypass heart surgery, or when one is being sued, one will naturally look for the best professionals available.

When an organization needs a piece of software created or maintained, does it hire the best and the brightest programmers available? What attributes does the organization look for in developers? What are the organization’s wage scales, and what level of software skills does it get for those wages? My experience is that a software project manager normally gets only the talent already available in the organization, and that talent depends on the quality of the organization’s benefit package. Moreover, there are other priorities to be considered, so the project manager does not get to choose the best and brightest engineers available. Sometimes the project gets super programmers. Sometimes not.

I am not aware of any published studies of this (perhaps I have not looked hard enough) but based on my experience, most developers are only given low-skill piecework tasks. They maintain existing applications. They fix bugs. They help customers deal with known problems. They clean up reports and GUIs, they back up data, they make sure libraries are included in the latest builds. These are not intellectual tasks. These are chores: tasks are simple, originality is not desired, elegance is not recognized. The organization simply wants these tasks completed on schedule. Only a few developers are given tasks that could be considered original, creative, or intellectually challenging. (Naturally, some latitude must be provided when certain developers or teams have tasks that require creative thinking and experimentation. But does it make sense to allow the same latitude for all other development tasks?)

While it might be argued that most doctors and lawyers also spend their time on routine tasks, it should be noted that doctors and lawyers deal directly with their clients, and that there is a direct relationship between professional actions and clients’ well being. This is a major aspect of the professionalism of doctors and lawyers, a major motivator for continuing education, professional ethics, and passion about treatments and strategies. But is this the case with software developers? Some software maintainers occasionally contact clients. Other parts of the organization (not development) usually screen customer problems and customer requests, turning them into bug reports or design documents. Test groups stand between developers’ work and the clients. (If the product works in the field, the developers take the credit. If not, the test group usually gets the blame.) Even during crises, there is little direct interface between developers and clients.

Raelin (1984) describes professionals as being passionate about choosing methods, protocols, courses of action, tools, and procedures. Professionals go even further—they often want to choose their own tasks. On the other hand, while one can usually uncover some emotion about tools (try telling a C coder that the organization is going to adopt Ada as its standard language), software developers seldom show passion about development methodologies or quality initiatives. Software developers do not choose their own tasks. Developers are assigned tasks, usually accompanied by deadlines. Development teams are usually left to derive low-level design requirements and to produce their own schedules—but then management figures the schedules are probably sandbagged, so the schedules are arbitrarily shortened. Then the requirements are changed, often several times. Or worse, the requirements are only vaguely defined, allowing marketers or other managers to object to nearly finished products, causing panics to reformat the product. Methodology is seldom given enough attention to cause any serious discussion among developers, and probably never among upper-level managers. It is hard to associate this mode of work with Raelin’s characterization of professionalism.


It takes fortitude to maintain discipline among developers. Software developers resist discipline. They do not like process management, they certainly do not like metrics, and they regard project management as mostly bureaucracy, despite any amount of evidence showing that these disciplines are effective. There is nothing pleasant about enforcing process discipline among people with such attitudes.

Since software managers are usually ex-developers or part-time developers themselves, they feel emotional conflict when forcing developers to adhere to processes and to maintain metrics. No software manager appreciates seeing his or her name written on the pointy-haired manager in a Dilbert cartoon.

More seriously, software managers understand that they may put their jobs at risk by disciplining software engineers. Software engineers are held in high regard by marketers and upper managers, and are excellent complainers. Unfortunately, careers are often subject to the despicable rules and conventions of the television series about “Survival”—outwit, outrun, betray, humiliate, complain. Software managers realize that the developers occasionally have opportunities to vote them out of the tribe.

Many software managers have little or no training or experience in project management. Even fewer have exposure to quality theory and methods. Such software managers hesitate to support or enforce quality activities they do not understand.

Please don’t get me wrong: there are software managers who are jewels—people-oriented, but also able to rule while getting cooperation from the team. They are masters of the technology and stay up to date. They enforce the best practices their management and their developers will tolerate. It is a great pleasure for a software quality engineer to work with such software managers. But how many software managers have such attributes? How many would like to enforce better methods but do not have the fortitude to do so? How high do quality activities rank among the priorities for most software managers?

Where upper management rewards managers for following processes, there is a good chance for process discipline and quality improvement. Otherwise, there is little chance of systematic management or improvement.

Where customers care about development capabilities, there will be better management discipline. Where customers do not care, there will be few incentives to define and improve processes.


Development and project managers may want the developers to be checked on, but as described previously, they may either dislike being seen as disciplinarians, may not understand software improvement theory, or may not see process enforcement as a priority. So it is not surprising that managers tend to dump the tasks of auditing and enforcing processes on someone whose job title contains “quality.” So here it is: a tough job, software quality engineering.

The worst way to accomplish enforcement of processes is to be rigid and ignorant. Software quality engineering is not an elastic product: one size does not fit all projects or tasks. Different jobs within a software development organization need different degrees of freedom. Where tasks are routine, process enforcement is appropriate: making builds, checking and testing releases, controlling configurations, doing backups, and many other activities should be accomplished by following well-defined processes and standards. These establish a foundation of trust, so that the organization can assume those activities are under control, in order to focus on more difficult tasks. More latitude should be allowed to developers regarding coding standards: developers should follow the intent of the coding standards, but should not be restrained to literal compliance with the coding standards when this would result in clumsy implementation. Likewise, latitude must be allowed to those who write specifications and create architectures. Even more latitude should be allowed to scientist-level developers who serve as experts on language, compilers, devices, and so forth. Intelligent software quality engineering starts with recognizing how much process enforcement is reasonable for these types of activities.

Similarly, software process discipline should be applied in proportion to the consequences of failure of the product in the real world. Would failure cause global thermonuclear war, loss of money, or merely inconvenience for users? What is the relationship between cost of quality problems and cost to improve quality for this particular product? For some products and some circumstances, it is a lousy business decision to put too much effort into quality initiatives.

The size of the organization also dictates how much effort should be put into software quality. I have two friends whose day jobs are writing software for big businesses. They are also partners in a tiny enterprise: they spend a dozen hours a week each developing and selling products for handheld devices. Tell me again why a software quality engineer would recommend that this company go for CMMI level 5 and ISO 9000 certifications and why it needs Six Sigma Black Belts? How about the team of five firmware developers in building three, working within a hundred-member hardware development business unit: what rationale does one use to explain to management why this group should get CMMI certified and dedicate one engineer to doing statistical process control? How about the 12-member software group in the office in Illinois? Or the two guys downstairs who are maintaining that old product that is going to be obsolete next spring? Again, software quality improvement efforts must be governed by reason. To insist that process enforcement techniques suitable to a big development project in a big organization must be applied to all other software projects and organizations and stages of product life cycle is sanctimonious—and stupid.

That said, it is clear that many software development organizations do profit from software quality engineering, and some customers have learned (through hard experience) to insist on disciplined processes and strong software quality engineering. So how does a software quality engineer proceed?

Recognize the obstacles: no software engineer wants a quality engineer constantly watching over his or her shoulder, checking on every task. It takes considerable intelligence and force of personality to monitor processes while maintaining good relationships with developers. It is hard to ignore the resentment of people being checked upon. It is not surprising when software quality engineers identify with Sisyphus, forever pushing uphill against lack of discipline. Developers have few incentives to follow good processes; managers have few incentives to discipline developers. Software quality engineers must be good practical psychologists to influence developers to cooperate, and must themselves work hard to ensure significant improvements in processes and quality.

It also takes intellectual strength to lead the development organization to understand the principles of quality. One cannot have effective software development when the development teams do not have fundamental understandings of software economics as explained by Boehm (1981), lessons learned (Brooks 1995), or good processes and reviews (Engle and Engle 2001; Fagan 2001). It is therefore up to the software quality engineer to have considerable technical depth, as well as knowledge of the organization’s requirements, and ability to lead both by persuasion and by discipline.


The software quality engineer must find a middle path between being an ineffective pushover and being a jerk who rigidly insists on enforcing processes. It has been my privilege to observe and manage a number of excellent software quality engineers, and they share a common trait: they are professionals. They study the organization, they stay up to date with software technology as well as with quality techniques, and they invest a lot of energy and emotion into their jobs. They also treat developers as professionals and colleagues, resulting in quality improvements and excellent morale. They are in demand by development teams, and they have helped make significant bottom-line contributions to the company. Based on these observations, I offer the following recommendations for software quality engineers:

  • Behave like a professional. Tell the truth, know what you’re talking about, be a leader and a problem solver, be an advocate of good practices, and treat managers and developers with respect. Read and apply Raelin’s book on management of professionals.
  • Be realistic. Understand which software quality techniques are likely to benefit the organization, how much effort the organization can afford to spend on quality initiatives, and when to allow (and even encourage) latitude.
  • Understand the psychology of quality engineering. Use techniques that will ensure cooperation for quality improvements, foster morale, and support software managers.
  • Help management recognize the symbols and behaviors that appeal to developers, and help identify incentives, rewards, and punishments that will be effective in improving processes.
  • Know how to program, preferably in several software languages. Understand databases, operating systems, source code management, syntax checkers, CASE tools, and automated test tools. Take a course in PSP or work your way through Watts Humphrey’s PSP exercises (1995).
  • Help identify and prioritize training needs. Take the lead in setting up training.
  • Look for good quality practices and lead the way in recognizing and commending these achievements.
  • Understand when and how to enforce processes, and team with software management to accomplish that enforcement. Understand that it will take fortitude as well as professionalism and good practical psychology to accomplish improvements.
  • Lead reviews, inspections, and teams, and make sure they are conducted effectively. Be proactive. Invest your time and energy into making these activities successful for everyone.
  • Don’t bad-mouth the developers or their existing processes. Develop process champions and use them as mentors.
  • Develop a road map for the organization’s software quality, mapping into business needs and consequences.
  • Avoid “process religion.” If one’s organization really needs CMMI or Black Belts or ISO 9000, then lead the way. If not, one should be honest in his or her recommendations, and quietly and persistently enthusiastic about a chain of small, gradual improvements.
  • Attend professional conferences, make presentations there, publish, and encourage developers also to do so.
  • Become known as a master of the literature in the fields of software development, management, and quality.
  • Belong to ASQ. Subscribe to Software Quality Professional and read it!

The software quality engineer must find a path somewhere between rigidly enforcing discipline and failing to meet the organization’s obligations to its shareholders and customers. The ethical software quality engineer is responsible for making sure the right thing is done: agreed-upon schedules and organizational and customer needs must be met. As Watts Humphrey illustrates in his book on managing technical people (1997), software management must be able to lead with a carrot, but also be able to motivate with the stick. As a software quality engineer, one should understand how to influence engineers, motivating them to act as professionals, perhaps using the aforementioned suggestions. But as occasions require it, one must also have the fortitude to bare the teeth, help enforce discipline, and endure, to prevent a project from failing. Good luck.


Boehm, B. 1981. Software engineering economics. Upper Saddle River, N. J.: Prentice-Hall.

Brooks, F. P. Jr. 1995. The mythical man-month: Essays on software engineering, anniversary edition. Reading, Mass.: Addison-Wesley.

Daughtrey, T. 2002. From the editor. Software Quality Professional. (March): 4-5.

Dunn, R. H. 1990. Software quality: Concepts and plans. Englewood Cliffs, N. J.: Prentice-Hall.

Engle, C. B. Jr., and C. M. Engle. 2001. Get it right versus get it out. In Proceedings, 11th International Software Quality Conference.

Fagan, M. 2001. Hitting the bull’s eye—Improving your quality, schedule, cost, and performance. In Proceedings, 11th International Software Quality Conference.

Ford, G., and N. E. Gibbs. 1996. A mature profession of software engineering (CMU/SEI-96-TR-004). Pittsburgh: Software Engineering Institute, Carnegie Mellon University.

Humphrey, W. S. 1995. A Discipline for Software Engineering. Reading, Mass.: Addison-Wesley.

Humphrey, W. S. 1997. Managing technical people: Innovation, teamwork, and the software process. Reading, Mass: Addison-Wesley.

Perry, W. E. 1991. Quality assurance for information systems: Methods, tools, and techniques. New York: John Wiley & Sons.

Raelin, J. A. 1984. The clash of cultures: Managers and professionals. Boston: Harvard Business School Press.

Schmauch, C. H. 1994. ISO 9000 for Software Developers. Milwaukee, Wisconsin: ASQ Quality Press.


Dave Miller has managed quality and test organizations in telecommunications companies for two decades, and has published papers on software quality models, design of surveys, and surveys of engineering groups. He has a master’s degree in information technology from Drexel University, a doctorate in English from Duke University, a master’s degree in English from the University of Michigan, and a bachelor’s degree from Montana State University. He is a member of ASQ, IEEE, and ACM. He alternates between irreconcilable opinions about the role of software quality engineering. He can be reached at


If you liked this article, subscribe now.

Return to top

Featured advertisers

ASQ is a global community of people passionate about quality, who use the tools, their ideas and expertise to make our world work better. ASQ: The Global Voice of Quality.