HW12: Mythical Man Month

The Mythical Man Month compares large system programming to a tar pit. The more an animal struggles to break free from the pit, the farther it falls and more stuck it gets. For developers, the complexity of a large system compounds when trying to resolve small issues and more arise. Further pulling down productivity. Optimistic scheduling of completion of a project is the cause of most projects being late and over budget. He goes on to say that part of this is because programming in its nature of creating attracts optimists. I agree with that statement. The thought of creating something new or doing an old task in a better way is what attracts me to this field. I have fallen into the trap of being too optimistic with my time when programming and something that was estimate to take 10 hours ends up taking me over 30 hours. Testing and debugging is the demise of most developers that are already behind.

The man-month concept is wrong in that it assumes that men and months are interchangeable. Most of the time the first thing a manager that does not understand development will start adding men to a project after it is already behind. I once saw this at a company I previously worked for. The software they were working on was not meeting certain deadlines for individual functions that were to be added to the live version. This was partially because before the development team could finish the given assignments, they were given new specifications on other pieces that were deemed more critical roll out. The VP of development decided they would hire 4 new developers to finish the previous functions that were started and have the current team get started on the new functions. This of course did nothing to speed up the development schedule. Most of the developers became annoyed with the fact that they were spending more time showing the new guys what they had started then actually writing code. One of them even quoted the mythical man-month in a meeting. Fig 2.4 shows how once there are too many men added to a project, the amount of months necessary for completion go up. This is due the intercommunication that must go on for the newly added group to get up to speed. Once it is determined that the project is behind, most managers will not reschedule the completion date which I feel is the best solution when the deadline has been underestimated.

Breaking up the development team into designated roles removed from the actual coding can serve to speed up the development process. No longer will the programmer be concerned with making test cases and other supporting tasks. The main coder will be able to focus on getting the function completed. I believe separating the roles is the way most companies are heading. New graduates often get jobs as testers or quality assurance specialists. The ones actually producing the product have many years of experience.

Conceptual integrity is often overlooked and causes a program to be delayed by the addition of new “smarter” functions. In the case of my previous employer, they started the project with a few very clear goals setup. Over the year it was being developed, so many things were added and/or changed that its focus did not even remotely resemble the original plan. They were perpetually going between architecture design and implementation without ever getting to realize the finished product