Book Review by: Bill Schell:
"The Mythical Man-Month"
(20th Anniversary review issue)
by: Fred Brooks - Addison Wesley; ISBN: 0201-183595-9
If you were to read this title / subtitle pair -you might get the impression that this guy had written a book, 20 years ago, about software engineering, productivity, quality, and the like, and then 20 years later decided to re-visit the issue, and found that little has changed
You'd be right on almost all counts- and, IF you're a software professional (and were around 20 years ago, doing software (like I was)) you'd probably also be embarassed and frustrated, to say nothing of apalled at how true all of this is.
Some of Brook's main points, 20 years ago, amounted to:============
 
  • Software development is a "tar-pit"
  • Software development is an art, as well as a science
  • Improvements in software development cycle time have more to do with project management & people than with technology
  • Software was a "custom" business 20 years ago (today it is almost a "commodity" business
  • From a  "software program" to a "programming system" requires 3x effort
  • From a "software program" to a "programming product" requires 3x effort
  • To go from either of those to a "programming systems product" requires an additional 3x effort
  • THEREFORE to get from a "program" to a "programming systems product" requires 9x effort and that's a lot of effort that (sometimes) management didn't count on.
  • a proposition for a "programming team" - similar in structure to a surgical team, outlined this way:
  •     Surgeon (or "chief programming" or "systems architect")
  •     co-pilot who backs-up the above person
  •     administrator (personnel, raises, space, ordering, money, machines, etc.
  •     editor - handles all issues related to documentation
  •     two secretaries for all above miscellaneous items
  •     program clerk - in our terms  a configuration management guru to take care of versions, builds, etc.
  •     toolsmith - our SETC
  •     tester - for all types of testing, unit, integrated, user, interface, etc. etc. etc.
  •     language lawyer - the guru of structured language details & tricks of the trade -
    • that - perhaps - may be a better way to handle small to medium sized projects, as well as modules for a much bigger project
     
  • all programmers are opimistic, "All will be well"
  • Good cooking takes time - some things cannot be hurried
  • patitioning the task among mulitple people or groups ocasions extra communications effort

    • and - finally:

    "The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable." ----- (Most evidence proves this to be false (B ill's annotation))
     

    Some of the things he thinks have changed are:=============

     
  • The PC revolution has allowed developers almost instant compiles (compared to 20 years ago) and enough memory and hard-disk space to do almost real-time debugging of linked and/or un-linked code.
  • Shrink-wrap is a real market-force for either a complete solution and/or solution 'pieces' (objects for sale (Such as NeXT's "WebObjects" suite))
  • Object Oriented technology that hides the "complexities" of the data and how to handle it really was a "silver bullet" - but requires a significant up-front investment and long-term commitment (witness - again - NeXT & their 12 year commitment to an OO OS, amongst other things.
  • 20 years ago - there were probably 30-50 OSs; today, only 5 OSs in the "public market":
  •     Apple Macintosh OS / OS Server (also Unix)
  •     IBM's mainframe "interactive" OS: VM-CMS
  •     IBM's mainframe "batch" OS: MVS
  •     Microsoft - Windows
  •     Unix (including Solaris, HP-UX, SGI, DEC,  IBM-AIX, Linux, etc. etc. etc. )
    • Implying the market has less saturation in target systems, but more volume
     

    AND - Some of things he thinks have not changed, are:============

    1.) the low-hanging-fruit / quick-increases in computer software engineering / writing (such as OO) are basically "all gone" - the future requires better people, but more, yet, better project management

    2.) Adding additional headcount to a large and already late project doesn't necessarily improve the delivery time nor the productivity - simply because the assimilation of those new bodies requires a decrease in the productivity of the existing staff, and it also introduces new communications channels that detract from everyone's productivity.

    3.) Documentation (and/or self-documenting code) is still a VERY good idea, and one that
    too few developers, managers, and project leaders are willing to spend the time in / sacrifices for

    4.) Re-use still probably has the single greatest potential for improvement in productivity, but it's implementation (including management of the libraries and the rewards system(s)) is / are risks and costs & investments of time that few managers and/or customers are willing to invest in for a "4th to 6th project return".  That all the studies and all the research and all the trials & prototypes have proven that the up-front costs (of all types (people, capital, expense, etc.) have proven that few re-use systems begin to return their investment until the 4th (sometimes) or 5th project (mostly) project after initialization of the re-use system(s).   It requires a very strategically focused & committed management group with a long-term budget view to make this happen.

    5.) the final key point is that people and their abilities to think-out-of-the-box, their abilities to work as a team and to share both the down & up-sides of a project will still make more productivity gains than any & all technologies issues.  This should encourage us to go forth, spend more time & effort to find the best people in the market, and then focuse even more energy in grooming them, nurturing them, finding out what motivates them to want to work for Motorola in the first place, and what we can do to keep them in the second place.