The Mythical Man-Month

For this response, I will be responding to the following article: The Mythical Man-Month

For starters, I think it is important to note that just because a program works does not mean it is done. I can write a program that calculates the traveling salesperson problem (just a hypothetical, simplistic example, unfortunately) in polynomial time, but if there is no documentation, no way for anyone to use my results, no way for someone to read my code, then what is the point? It would be much better to have this program written with ample documentation, readability, etc along with directions for setting up the extinsibility (assuming open-source). Also, just because the program works does not mean it is the best. What if the program I wrote only works on my souped up computer that has terabytes of space. What if someone wants to use this on a lighter rig? There is no way that anyone with a reasonably-priced computer would be able use it. Memory space, I/O devices, and computer time are all important things to consider in code. Getting the program working is merely part of the overall process that is software development and engineering.

Let's say you do get the program working. Well, how long did it take? Did it take longer than you expected? The answer is most likely yes. The Mythical Man-Month cites the optimism of programmers and this makes sense in the context of this situation. At the beginning of a project, you are to over-exaggerate your own planning and computer skills. This only makes sense though because if you do not look at yourself and your skills in a good light, then how would you even get a job or have the motivation to do anything with your skills. Being an optimist produces results.

I had never heard the term man-months and did not even know what it means. A man-month is a way to refer to payment for a software project (people working on project times the months to complete the project). It makes perfect sense that this would be a terrible measure, in general. The author mentions the non-interchangeability of these two variables. If this were a good measure, then I should be able to double the speed of a projects completion by doubling the amount of people I have working on a project. It just doesn't work that way. Explaining this would require the use of a logarithmic graph (Obviously this is not always true - I feel it is just the typical case). This is because you can reach a point where you can have so many developers that one more is not going to add to the speed or quality of the project in the end. You can also have a project that is doomed to never complete due to bad design and poor requirements elicitation from early-on. These projects will not be able to make it to completion unless major changes are made. You cannot simply just hire someone else and have a linear relation between months and workers. As the author puts it, sometimes there is no threshold of people that can even affect time (the analogy of no matter how many women we introduce, there still is just one period of being pregnant that has a fixed time).

The next few sections of The Mythical Man-Month pretty much boil down to a few things that I stated here and a few others. Never undercut the time you think you need on a project. Always leave time for debugging and fixes - even "perfect" elicitation of requirements can still result in a number of bugs and issues. Make sure each member of your team fits into the role that they have on their project and make note that anybody can act in any role, but defining primary roles is always important (ex// a Software Architect can aid in the writing of a Systems Test). This fits into the 'Surgical Team' analogy where roles have been divided up. But even in surgery, anything can happen, anything can go wrong, and improvisation can become a necessity, as aforementioned. The improvisation is a little different from the author's intention, but I do feel that it is a corollary that needs to be added.

Considering everything, it is important to have a well-defined role in a project. It is crucial to have realistic, not to imply optimistic cannot be realistic, goals and deadlines. It is vital to be able to understand other parts of the project. I added this last point because I feel like it just needs to be said. If I'm a database administrator, I can work all day and really not know what is happening on the front-end of my application, but is that what we really want? Of course not. I would need to understand what is happening in the application. The nature of the security of the information may not be evident until understanding the rest of the application. All things said, the man-month is a ridiculous idea and this myth has been confirmed.

Music listened to while blogging: Robin Thicke & Sublime