Information Technology Reference
In-Depth Information
arose about the accuracy of Baker's assessment; Mills's system eventually
proved unsatisfactory and was replaced with a less ambitious system.
48
For the time being, however, the
New York Times
system was considered
to be proof positive of the effi ciency of the CPT approach.
Several objections to the CPT approach were raised in the contempo-
rary industry literature, though. The fi rst is that it was diffi cult to fi nd
individuals with enough talent and energy to fulfi ll all of the functions
required of the chief programmer.
49
The few who did exist were expen-
sive, and were not interested in working on small computers and mundane
applications. A second problem was a perceived overdependence on key
individuals implied in the CPT approach: “What happens if [our super-
programmer] snaps up a more lucrative offer elsewhere? He'll likely take
our back-up programmer with him, leaving us high-and-dry.”
50
A number
of observers suggested that the surgical team model led to excessive
specialization.
51
The computer scientist C.A.R. Hoare derided the small-
team approach as a retreat “to the age of the master craftsman—more
fashionably known as a chief programmer.”
52
There were widespread
doubts about the ability of the small-team approach to scale up to the
needs of large development efforts.
The most revealing criticisms of the CPT system, however, had to do
with the ways in which the presence of an elite administrator/program-
mer disrupted existing patterns of managerial authority: “The CPT per-
petuates the prima donna image of the programmer. Instead of bringing
the programmer into the organization's fold, it isolates and alienates him
by encouraging the programmer to strive for a superhero image.”
53
The
CPT allowed for little participation by nontechnical administrators. A
textbook,
Managing Software Development and Maintenance
, from
1981 corrected this perceived overdependence on technical personnel by
proposing a revised chief programmer team (RCPT) in which “the project
leader is viewed as a leader rather than a 'super-programmer.” Whereas
the chief programmer was clearly a technical specialist, the project leader
was “an expert conceptualizer, designer, and project manager”—but not
necessarily a superprogrammer. Because the project leader possessed
both project management and technical skills, they were “able to direct,
oversee, and review all technical functions.”
54
The RCPT approach was clearly intended to address a concern faced
by many traditionally trained department-level managers—namely, that
top executives had “abdicated their responsibility and let the 'computer
boys' take over.”
55
As was described in chapter 7, it was this fear of
