erhaps the finest work on
managing software projects is a book called "The Mythical Man
Month". Written in 1975, it’s relevant even today. I first came
across the book during college, about 15 years ago. I enjoyed reading it,
but lacked the experience and maturity to really appreciate what it said.
The book was long unavailable to most practising professionals in India but
has now been released in an Indian edition. It’s essential reading for
anyone connected with software development, as this column will show.
First the author–Dr
Fredrick P Brooks, Jr.
Dr Brooks was the architect of IBM Stretch and Harvest computers. He is
widely regarded as the father of IBM’s revolutionary System/360 computer,
having managed both the development of the computer and operating
system/360. The book was a direct outcome of his experiences in managing the
development of OS/360. Dr Brooks subsequently returned to academia and
founded the Department of Computer Science at the University of North
Carolina at Chapel Hill.
The book is a series of
inter-related essays with a common theme–that is, the complexities
inherent in large-scale software development. The book can be credited with
having created permanent images in the minds of software professionals, some
of which I detail below.
The book opens with a picture
of dinosaurs stuck in a tar pit. Their struggle only increases their state
of entanglement. Dr Brooks likens this struggle to the battle inherent in
trying to finish a large programming project on schedule and under budget.
No matter what you do, you get further enmeshed instead of being liberated.
Dr Brooks then moves on to an
essay with the same name as the book–"The Mythical Man Month".
The central point here is that man-months is an inherently flawed measure of
a project’s size. The central problem with this measure is that it ignores
the fact that the more the number of men on the job, the greater the
communications and coordination overhead. Thus, adding more manpower to a
job may slow it down due to increased problems in coordination. He uses some
memorable phrases to illustrate the situation and likens the process of
adding more manpower to a delayed project to "dousing a fire with
gasoline". The essay ends with Brooks’ Law–"Adding manpower to
a late software project makes it later".
"The Surgical Team"
is a beautiful essay on the composition of the ideal programming team. Here,
the programming team is compared to a surgical team. "Aristocracy,
Democracy and Systems Design" propounds the theme that conceptual
integrity is the most important consideration in systems design. "Why
Did the Tower of Babel Fail?" deals with using a project workbook to
organize large projects. "The Documentary Hypothesis" advances the
concept that the management of a project pivots around a small number of
documents. "Plan to Throw One Away" advances the hypothesis that
no matter how you design, a second version will be required. The first
version should be treated like a pilot plan, from where you’ll learn what
actually should be done.
contains a reprint of a classic 1986 paper called "No Silver Bullet—Essence
and Accident in Software Engineering". The thesis behind this was that
no single technology in the next decade would be able to bring about
significant improvement in software productivity. The thesis was developed
by dividing the software development process into essence and accident. The
essence of software development lies in creating the conceptual constructs
that form the basis of software. The accidents of software development lie
in representing these constructs in machine-processable format through
suitable languages. Dr Brooks argued that all previous increases in
productivity had come through attacking the accidents through tools like
high-level languages, better environments, etc. He then pointed out that a
process of diminishing returns was at work and what was really needed was an
attack on the essence. He did not foresee any dramatic breakthroughs in this
regard and history has proved him right.
The book contains a side
treat in the historical details of development of OS/360. Here, Dr Brooks
regrets wasting 26 bytes for processing dates for leap years. At other
places, he discusses how programmers were given budgets in terms of memory
space. Enthusiasts will find lots of other interesting tidbits too.
The bottom line "The Mythical Man
Month" is compulsory reading for anyone remotely connected with
software development.