The Mythical Man-Month (1974)

Eh. Very interesting and potentially useful concepts - at least, if I were planning or managing a major software project. But as soon as he gets down to details, it turns into a mildly interesting discussion of computer history. When he spends an entire chapter (well, nearly) on the advantages of time-sharing terminals as opposed to batch debugging...yeah. Not really helpful in terms of what we've got now. The final chapter - the update, as of 1995 - is more interesting but still outdated - he spends a lot of time talking about this wonderful new thing, object-oriented programming. Which is useful, in exactly the ways he discusses - but it's also the way I learned programming in college, so he doesn't have much he can teach me. The most interesting part, actually, was when he pointed out that about then, the 1990s, there had been a major switch in programming - it went from basically all custom-built programs, designed from the ground up for one particular company and usage, to what he calls "shrink-wrapped" packages like Excel and FoxPro, where the program is built to be general-use with thousands or millions of users each working with it slightly differently. It does make a major change in considering the programming process - the specification of the program get both looser (because they don't have to match one client's specific needs) and tighter (because they have to be useful in a whole lot of different situations). The cost variable does too - if you're spending thousands of man-hours on one program for one client, it's a couple hundred thousand dollars minimum to make it worthwhile. If you spend those same thousands of man-hours on one program that will be bought over and over and over by different clients, each one can be quite cheap. I wonder if MS Office pricing is a remnant of the older cost structure? It's not thousands of dollars, but it's pretty pricy for what you get. Anyway - the point is, by the time I was paying attention to commercial programming, shrink-wrapped was the norm and custom was that weird way government and a few retro companies insisted on getting software. I really hadn't realized that it had ever been another way. So - I learned some things, the history was interesting, but that's a read-once. The concepts might have been useful, but the illustrations used are so out of date that I can't apply them to anything I'll actually do. So, as far as I'm concerned, no longer a particularly useful book. Glad I read it, don't need to (ever) reread. ( )

04/23/11

Dr. Brooks is the founder of our department, more than enough reason to read his book.

The recent extension to our department building was named after Dr. Brooks. Apparently the money for the building came as an anonymous donation from an alumnus, on the condition that it be named after Dr. Brooks. That is the kind of respect he has won from several people. ( )

Even after 15 years from the publication of the anniversary edition, this software engineering and project management classic has remained surprisingly relevant. It presents many ideas that have since become very famous, like that adding people to a late project may only serve to make it later. Sure, there are some parts that haven't aged as well, but even those have historical value. The book certainly clarified my thinking on large software projects, and provided lots of valuable fodder for thought. Brooks's thoughts on conceptual integrity, the intrinsic complexity of problems and abstraction are insights that every software engineer needs to flourish. If you don't get them from this book, be sure to get them elsewhere. ( )

a

I was intrigued to find my computer-programming-major son reading the 20th Anniversary edition my favorite book from my career days (before he ws born!). He verified that nothing much has improved in computer programming since I quit teaching in the Eighties. Brooks's additional four chapters confirm most of his original work, with a few exceptions. ( )