One Mythical Man-Month Later

Good evening interwebs!

As some of you may have guessed from the title, I have just finished reading "The Mythical Man-Month" by Fred Brooks.  I can't remember exactly when I started reading it, but I think it's been about a month. For the record, while I generally don't read things very fast, this only took a month because it was read almost exclusively while on the bus.

I must say, I hope that Mr. Brooks has come to appreciate the humor to be found in reading the book today.  The fact that it's first listed copyright is in 1972 would make it 40 years old and would make the images of prehistoric creatures on its cover terribly ironic. There is an underlying hilarity in the juxtaposition of the books wisdom, which is just as applicable today as it was 40 years ago, and it's technical land marks, which come from a time long ago when fortran was advanced and programming in assembly was common practice; when computers needed operators, scheduled machine time, and occasionally lubrication; and when a text editor was a business luxury in the same vein as an in office pool.  To give you an idea of what I'm talking about, frequent explanations of the complexity of programming systems made reference to overlays.  I asked around and no one knew what they were off hand.  When we looked it up, it was pretty close to what I had been thinking:  overlays were basically virtual memory for storing the executable code.  Not the data, the code itself.  Today, the entire program usually just sits on one end of the stack.  This is back when ram was measured in kilobytes.  KILOBYTES!!!!

Anyway, I said briefly that the books wisdom transcends it's technological references (though not in those exact words), and it does.  Having read it, I am forced to look at my own work, both professional and academic, in terms of the surgical team and the architect, the implementation and the design.  Looking at stratagem this way is, admittedly, a bit weird, since the dev team consists entirely of me, myself and I (the big three).  All at once I am forced to play the roles of manager, architect, surgeon, toolsmith, language lawyer, and secretary.  On the upside, interteam communication is almost detrimentally easy.  For the most part, I've stuck to playing the architect, at least until I have a clearer specification done, but in time I will be switching hats.

I heartily recommend this book to anyone who will be working in a group software project, or even around one (psst that means ALL my fellow gamedev people).  Brooks' style makes for an excellent read, and while a lot of the technical references were a bit garbled due to age, I never had to struggle to understand the point.  It's easy to see why this book is one of the holy scriptures of software engineering.

I might talk a bit more about this in the future, but I really have to get to bed.

So thank you thank you readers for your reading, thank you Colton for lending me the book, and a big thank you to Mr. Brooks.

Oh and thank you to my commenters, whom I hope will someday number more than one.

Goodnight.