I read the original mythical man-month essay published in 1974 and i want to jot down some of my thoughts and lessons gleamed from such a classic paper.

The essay is pretty short and easy to get through and i finished it in less than 2 hours.

It talks about software projects and describes some fallacies we experience when estimating software projects. The essay originated from a question that was asked to the author Fred Brooks during his exit interview: Why is managing software harder than managing hardware developments?

The first thing that caught my attention was the statement "All programmers are optimists". This leads us to think that all will go well and this probably leads us down the path of poorly estimating software projects and can heavily impact the management and delivery of software.

It should also be mentioned that for human makers of things, the incompleteness and inconsistencies of our ideas are never evident during the conceptualization phase but only during implementation. This, I have found to be extremely true because only during implementation do we step out of the theory and apply the ideas to the physical medium and therein lies the opportunity for loopholes to surface.

Estimation for single tasks vary from estimation for large projects. For a single task, the probability that all will go as planned is true but for a large programming effort, that probability is nearly zero. This should be factored into the estimation of the project; everything will not go as planned.

Man-month implies that men and month are interchangeable and this as a unit of measurement for a software project is a dangerous concept. This unit of measurement works in the industrial era but not in an intellectual capacity. If intercommunication and training are not involved, then this unit of measurement might suffice but in large programming effort, this should be discarded. A wonderful analogy to illustrate this point is "Child bearing takes 9 months, no matter how many women are assigned".

An important concept i learned is that the effort of communication must be added in the amount of work to be done. I've never considered this before but this is so true especially if communication is required between partitioned tasks and also external communication between two different parties (I'm currently struggling through this right now).

A detrimental fallacy talked about in the essay and I've also experienced personally is the fact that if more manpower is added to a project, the faster the project can be completed. This is quite the opposite especially if tasks require coordination and inter-communication.

A good rule of thumb to follow for scheduling a software task:

• 1/3 planning
• 1/6 coding
• 1/4 component test and early system test
• 1/4 system test, all components in hand.

Failure to allow enough time for system test, in particular, is peculiarly disastrous. It is therefore very important to allow enough system test time in the original schedule.