Almost everyone has every heard of or read about the “mythical man-month”. Most agree with its premise. In its most distilled form, it means that there is no way to capture a unit of work that will be the same for everyone. It has been proven again and again that programmers have different skills and speeds. It is not easy to quantify this work for a few different reasons.
The first problem is that experience can make a big difference. In most cases, experience can help to speed the resolution to the problem. However, sometimes experience can hinder the development of a better solution. This is the classic case of young versus old. Each always thinks that the other doesn’t know what they are doing. Overall, however, experience is an asset that can help guide the code and the project to success. The real question is how do you measure experience?
The second problem is that often the work being done is new. Most manufacturing jobs are about doing what has been done many times before. It is much easier to predict and manage the work flow of a factory than it is to schedule software for a new feature that has never existed for that company. The more challenging the project the less likely the schedule will match reality. The discovery aspect of this work is often discredited simply because it exposes unknowns and makes it scarier to fit into existing models and time schedules.
Even though everyone understand the “mythical man-month”, it is still repeated over and over within the industry. What happens is that the team leads and managers get together and decide how long it is going to take for a new juicy project. This work is done without taking into consideration the team that will be working on it. This is not always the case, especially if the team lead is involved and actually programming for the project. Once the work has been estimated by the managers/team leads, it is then dictated to resource the effort. It goes something like this, ” We need six developers to complete our project by year end so that means we should go hire or contract people in to complete this work”.
Does anyone see the flaw in this thinking?
Well, I’ve seen this a number of times in my career. It was especially true at IBM in the early 90’s. The point is that programmers are not a commodity (at least not yet :)) and that the variance in skill is huge. On top of this, you cannot assume that a contractor or new-hire is going to have the experience you need to get your project to be good.
From a more fundamental level, you cannot put together people and expect a functional team to happen. It takes work and real decent selection processes to make sure that you have the right group.
So, the message is that you have to be a bit more wise with how you manage your team, you will see the benefits of better estimation of schedules. It is not going to happen in a vacuum.
The conclusion I have been reaching lately is that things like the “mythical man-month” happen because, in some way, the environment encourages it to happen. Probably, it is viewed from managers that do this that no programmer has a higher value than another. Or, more correctly, one programmer can always be replaced with another and be just as good. This is more about hiding a weakness than respecting the fact that skills vary and that programmers are never the same.
Another conclusion is that programmers should not tolerate this kind of treatment. It should be actively resisted for the sake of a better programming environment. Obviously morale will suffer if everyone is supposed to be as good as every body else when it is not really true. In a way, it is like a strange variant of communism. Everyone is treated just as badly as everybody else. 🙂
Perhaps the darker side of “man-month” is that if it was revealed that programmers have different skills and speeds and this was reflected in the schedule, certain programmers might grow jealous and it would help to dissolve the hopes of teamwork. I suspect jealously would not happen if the team was strong enough to start with. Respect and trust tend to dissolve jealousy.
The concluding point is that “mythical man-month” is still true and it is still active in 2007. I’m just wondering what it will take to shake it out of the tree so that we can move onto more modern approaches to accomplishing projects.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 