Homework #9

Response to The Mythical Man-Month

Frederick Brooks is an author our class has read before- if you go to my first blog post there is a little snippet about him.  He wrote an article about the silver bullet of programming and I distinctly remember werewolves being all over his article- now there are dinosaurs all over this article and programming is being related to a sticky tar pit.  I like this man's style.

A quick Wiki search informed me that this article was written about Brooks personal experience as manager of the development of IBM OS/360.

The first chapter talks about the joy's and woe's of programming.  I could relate to most of the good and bad of programming, but the one I ended up highlighting was a paragraph talking about perfection and programming:  "If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program."  Syntax.  I'll go through an emotional roller coaster at times when my code is not compiling and I'm trying to fix the problem- a half hour later, I realize there's a comma missing.  Syntax.

The second chapter introduces Brooks law:  Adding manpower to a late software project makes it later.  The first and last sentences in this chapter is the same sentence:  "More software projects have gone awry for lack of calendar time than for all other causes combined."  Adding more men, causes problems with communication.  Also managers have to consider that adding men will require training as well.  Time management and software engineering are difficult to keep in sync.  Brook suggests that "We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on." to get a better handle on project time estimates.  I found myself giggling out loud when Brooks says "The bearing of a child takes nine months, no matter how many women are assigned."  He relates this to software because of the sequential nature of debugging. 

The third chapter tries to answer this question:  "For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?"  Brooks suggests working as a surgical team would to tackle the software project.  Everyone has a role and the surgeon makes the final decisions that everyone else on the team helps support.  I have heard of employees working for large software companies who "get by" with contributing little to no work.  Since their corporations are so big, it is hard to keep track and make sure everyone is doing their part.  I think this surgical team approach would be very beneficial to companies.

The fourth chapter.  Brooks believes that  "conceptual integrity is the most important consideration in system design."  Brooks shares a costly mistake he made with the IBM project - what he learned was that more man power degraded the conceptual integrity of the project- which took more time and more money to rebuild and fix.

I enjoyed reading about Brooks personal experiences with the IBM project- the mistakes he made, his "Aha" moments, his advice.  Learning how to work the most efficiently and productively as a team while creating software is something that we need more intel on.  As a former nurse, I remember being taught how a hospital team works in the midst of an emergency- who has what role, and what is expected of you.  There were diagrams, there was research, we play-acted our roles- we knew the proper way to respond.  In time, I think software engineering teams will have a similar look.