Hi there! You've reached the homepage of Ben Lavender! Ben is a computery person who partakes in many kinds of nerd tomfoolery, but mostly programming! You've found his home on the web, with the caveat that a lot his day-to-day stuff ends up on social networks, so this site makes him seem pretty stodgy.
Enjoy your stay.

BHUGA WOOGA!

The Mythical Man-Month

28 Sep 2009

The classic. I am not so sure it held up well.

I first read this about 8 years ago. I was not ready, and even worse, I somehow managed not to get the 1995 anniversary edition.

The truth is that most of this book does not hold up to the test of time as useful advice. While interesting and quirky, stories about static layering utilities as examples of programming management gone wrong are just not really useful. Advice from the era of computing in which it was done by companies like IBM seems almost surreal. Make sure your best programmers get offices equivalent to the best managers. What? Where do programmers have offices?

The real gems are in there, though. You need to know what you are looking for to get them, so I’m not sure this is the book to get them. But they are there. Software collaboration is harder than solo coding. A good programmer is 10 times more productive than a mediocre one. Bad or inexperienced additions to a project do not help it marginally, they actively hurt it. Making programming to faster only ensures the poor quality of the end product. Men and months are not interchangeable. All very important.

Brooks’ breaks it down to the problem of ‘essence vs incidental (he uses accidental, which I find a poor use of the term)’. He said that in 1975, most of a programmer’s time was already spent on essential work–programming is creative and difficult, and no amount of tooling can make that go away. It’s difficult to think of it that way now, when we’re slapping together databases and countless libraries on top of OS and library and driver stacks 10 layers of abstraction deep. So the problem has been solved by dodging it, making the programmer responsible for less and less with each new application framework. But we have still not found a way to make the creation of code easier, really. There are just fewer distractions.

I’m not sure I’d recommend the book today. As crucial as it would have been even just 15 years ago–already 20 years old at that point–it feels dated today; not really saying anything you’d notice unless you were looking for it, so why are you reading the book? A lot of the breakthroughs in here are simply common sense today. But it’s an easy read, and it was a classic with a lot of staying power. Physicists still read Newton on occasion for the history of it, and this one should go down in computer science for the same reasons.