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
|
