March 2003
Volume 5 • Number 2

Contents

TALKING POINTS
Bridging Between Software Management and Software Professionalism

By Dave Miller

TO UNDERSTAND OR TO DISCIPLINE SOFTWARE ENGINEERS?
Various social sciences have been invoked in attempts to explain how managers can better understand software developers. Barry Boehm (1981) orients his book on software engineering economics around the concept of “human economics.” Jerry Weinberg (1988) writes about the psychology of software developers. Steve McConnell (1996) offers practical suggestions for customer orientation, motivation, teamwork, and team structures. Tom DeMarco and Timothy Lister (1987) show how management can frustrate developers and vice versa. (These frustrations are also illustrated in Scott Adams’ “Dilbert” cartoons.) Recent articles and texts explore the culture and sociology of software developers (Mackey 2000; Wiegers 1996; Weinberg 1992; Glass 2000). An article in IEEE Computer even addresses the culture of software programs: programmers come and go and their skill sets change as the program evolves (Rajlich 2001). All of these authors imply that it makes business sense to accommodate software developers’ value systems and modes of interaction.

One therefore expects the literature about managing software engineers and about software quality to consider how software engineers think and work. Instead, many books about managing software and software quality recommend discipline, expressing disdain for software developers who fail to see themselves as workers and who resist following standardized processes. For example:

“Data processing organizations must equate their function to manufacturing a product in order to see the need for a quality control function. Data processing must assume the responsibility of determining an acceptable level of quality, and then establish the mechanism—quality assurance function—to determine that level is maintained. If you, the data processing professional, say, ‘My product is hand crafted and it’s a one-of-a-kind type product, so it cannot be measured and compared against a standard,’ quality assurance has little chance of success in your organization. On the other hand, if you say, ‘My skill is finding better ways to perform work, but the end product can be measured and evaluated against a standard,’ then the quality assurance function can perform a very viable service for you” (Perry 1991).

The quality industry generally assumes that the best results are to be gained by top-down enforcement of standardization and process control. These are requirements for ISO 9000 and Capability Maturity Model®(CMM) certification. Arguments for process discipline center on the assertion that defining and enforcing processes leads to better definition of requirements, improved efficiency and productivity, and overall success of the organization (Schmauch 1994; Dunn 1990; Humphrey 1995; Perry 1991). There is evidence that process discipline can lead to excellent results. For example, Michael Fagan’s inspection methods have been shown to result in cheaper, faster, and better results (Fagan 2001).

However, efforts to institute process control sometimes fail. The pattern of failure appears to be the following scenario: upper-level managers vow to “change the software development culture here.” Someone is nominated to institute a development process. The process is written without grass-roots involvement or support by the developers. Software developers are then ordered to follow the process. Perhaps a software quality group is set up. Perhaps there will be an initiative to become CMM certified. Sometimes this approach works, and the organization changes for the better. But too often, after a few months it becomes apparent that the process and the initiatives have caused disruption but have not benefited the organization. Projects stop using the process, and the process management initiative fades away. This scenario occurs too often to ignore.

A common denominator of such failures is a breakdown in communication between managers and developers. The success of process improvement initiatives appears to depend largely on how effectively management can influence software developers to support the initiatives, obtaining willing cooperation, fostering job satisfaction, and increasing morale. In other words, building bridges between management and developers helps the organization to improve process discipline. Software quality professionals can help build those bridges by understanding and appealing to the professionalism of the development staff.

The full text of this article may be found in the print journal. To subscribe go to /quality-press/display-item/index.html?item=SUBSCR_SQP .

Return to Top