Frederick Brooks published his essay The Mythical Man-Month in 1975, as one of 15 essays in the same-titled book on managerial aspects of software development. I wanted to check on the actual value of this historical piece of work. I have read the 20th anniversary edition, to which the author added an essay with his updated opinion on his original statements. This edition also holds the even more known 1986 paper No Silver Bullet.
The book: modern myth or ancient history?
The 1975 cases are technically not appealing (IBM’s OS/360) and hardly relevant for today’s technological environments. But the organizational topics are striking, with the title essay on top (justly mythical by itself). Although the core statement (“Brooks’ Law”) “Adding manpower to a late software project makes it later” has again been overtaken by history. But blame the myth of the man-month for confusing effort and progress, for neglecting the need for communication, for ignoring repartitioning tasks and training, and decreasing team productivity. People (developers) are not ‘replaceable pieces of machinery ‘! Brooks also stresses the creative nature of software development.
I agree on the diagnosis, but the suggested remedies (a lot on estimating and roles) are somewhat vague and far-fetched. E.g. 1/6 = coding, surgical team and ‘directors’/‘producers’, ‘aristocratic’ architects, etc.
But then, there’s the author’s 1995 retrospective seeming to make the lecture vivid again. He formulates views that are greatly in line with… Agile. But then (bis), Brooks doesn’t seem to recognize it and sticks to his ancient solution, i.e. a sort of surgical designers. But since the ‘90s we hàve seen the definite rise of Agile (this common denominator was only established in 2001!).
Can we today overcome the curse of the mythical man-month?
I believe that at least Agile does show a way out! Of the problems highlighted by Brooks, but in a very different direction than surgical design. Because Agile has a fundamentally different approach on communication and the ‘people’ aspect of software development.
e.g. Estimating is done by the whole team and in Story Points, i.e. complexity. This is at the same time the base for measuring progress (i.e. velocity being the number of Story Points realized in a Sprint), and avoids the confusion with effort.
In his Agile bible, Agile Software Development, Alistair Cockburn has substantially stressed the fact that communication hàs a cost, increasing our awareness of the impact on progress and budget. His views on Information Radiators and Osmotic Communication have meanwhile been greatly adapted by Agile teams.
