The Mythical Man-Month

I think it was in first year software engineering that we had to read this book, and nine years later I really, really understand the underlying purpose of this book. It may just be yet another book back then, but the lessons that are hopefully learned from it will last a life-time - not just for software projects, but any project.

The Mythical Man-Month

Unfortunately on software project plans, developers, designers, testers, business analysts, product managers, etc. etc. are considered "just another resource" that are added and removed off of tasks. The assumption is that all are equally effective and skilled in all the required domains, and all will produce the same volume and quality. So in a perfect world it makes sense to scale the team to meet deadlines, although we don't live in a perfect and linear world, this is still the method of choice. Even though the biggest effect of this method; drastically increased non-linear communication time is widely known but mostly ignored.

Sadly this is the state of this industry, project plans that are too often disconnected from reality. I think part of the problem is driven by dividing tasks into a unit of time, after all that is how budgets are built, teams are put together, and progress is tracked. However on the other hand, this unit of time does not measure the real size of the task. Its just an illusion. Its like a building, we don't measure building size in number of months it took to build, we measure it by number of floors or in meters i.e. something relevant and real. If a 40 meter building was estimated to take 12 months, and in 6 months we are at 10 meters, then we are 25% done, and not 50%. However if this building were a software project its assumed we are 50% complete. Then at 10 months we realize we won't meet the deadline, forget about the Mythical Man Month and scale up. Why did this happen? Because software does not have a realistic metric, software is abstract.

Some say you get better at estimating over time, but that too assumes we live in a linear world. Ex. Project X took us 3 months, so we will estimate that project Y will take 9 months. We don't live in a linear world, and humans aren't good at estimating non-linear stuff. We may think that the second project is 3x as long as the first, but it could be x^2. However the hope is that over time you can make a non-linear project more linear by improving the processes for the non linear components. That effort is also non linear.

You can try to measure by team size, effort, or lines of code, etc. but all are just an illusion of measurement, none are real. Whether you measure buildings by floors or meters, you can translate between both. On the other hand, you can't translate lines of code into time, effort or team size.

I don't know what a better alternative is, but surely it is not this. Perhaps the problem is just trying to estimate that far into the future with too many unknown variables. Feel free to comment.

I recently read the book "ReWork" by the guys at 37Signals and one paragraph I absolutely loved has to do with project estimation.

The book is a must read.