Information Technology Reference
In-Depth Information
than it does with its failure to address the “real” problem (which was
probably not technical in nature), or the implications that software has
on larger patterns of work, power, and autonomy.
The second lesson follows naturally from the fi rst: just as software
itself is a heterogeneous system and the software crisis is a refl ection of
that heterogeneity, so too must the solution to the software crisis be
heterogeneous. One of the appeals of software engineering as a solution
to the crisis is that engineers have long experience in developing such
complicated “systems of systems.” And yet even more established
branches of engineering struggle with the engineer's temptation to reduce
everything to a technical problem. From the earliest days of electronic
computing, users have been dissatisfi ed with the tendency of program-
mers to oversimplify complex business problems. And although the
context of software development has changed over time, laments about
the inability of software designers to adequately comprehend and repre-
sent the needs of users have not. Computer programmers in particular
sat in the uncomfortable “interface between the world of ill-stated prob-
lems and the computers.”
61
Design in a heterogeneous environment is
diffi cult; design is as much a social and political process as it is technical;
cultivating skilled designers requires a comprehensive and balanced
approach to education, training, and career development. As Frederick
Brooks observed in his “No Silver Bullet,” “The hardest single part of
building a software system is deciding precisely what to build. No other
part of the conceptual work is as diffi cult as establishing the detailed
technical requirements, including all the interfaces to people, to machines,
and to other software systems. No other part of the work so cripples the
resulting system if done wrong. No other part is more diffi cult to
rectify later.”
62
Finally, any proposed solution to the software crisis, whether it is
technical, managerial, professional, or otherwise, has implications for
individuals and organizations. The appeal of the software factory model
might appear obvious to corporate managers; for skilled computer pro-
fessionals, the idea of becoming a factory worker is understandably less
desirable. Whether or not such a model would even be feasible depends
a great deal on whether or not you believe software development as a
process can be decomposed neatly into individual tasks. The history of
software suggests that this is not at all an obvious or undisputed fact.
From this perspective, even the most seemingly technical debates
cannot be isolated from this larger context of occupational identity
and organizational power. As early as 1962, in a RAND Corporation
