Healing The Sick

The project I am working on would be classified as a Large project by most accepted industry standards. Because of its size, I find myself acutely aware of the differences between small team and large team development efforts. The things you care about and the inefficiencies you can afford are vastly different between these two types of efforts.

Lately, I got a chance to see the movie "The Pursuit of Happyness". In the movie the lead character is trying to become a stock broker and during his internship he has to perform cold-call sales. During one scene the narration explains that in the pursuit of success the character did things to improve his efficiency that others wouldn't. He wouldn't hang up the phone between calls so he could have more time calling. 8 minutes in a day. He wouldn't drink water so that he didn't have to use the restroom during the day. These are the types of things I really identified with.

Now of course, these are very extreme examples but the point is how little inefficiencies really add up. When you are a team of 10 everyone being 10% inefficient is really only about 1 additional body. On a short project you will likely be able to swallow that with some extra hours and extra effort by the existing team. When you have 100 people, the cascade effect from rework and lost time would magnify to a cost equivalent to more than 15 people! And this is even on a short project. As timelines get longer, the magnification is even more impactful.

In software development, optimism is a disease; feedback is the cure.
-- Kent Beck

The ways to counteract this impact from inefficiencies generally require more upfront work to codify engineering processes, checklists, review expectations, and so forth. You need to spend more time lay down the guidance on how the work will be delivered, how teams will get along, etc. When you laying out this guidance the processes will require more oversight, more documentation, and more tracking steps. It will generally require a much heavier footprint then equivalent processes used by smaller teams.

To put it another way, you will spend more time tracking what is being done because you simply must catch issues early and the cost to let things get off track is significantly higher.

Needless to say, I'm getting better at laying processes like that down in written form, but there is much more that could be done. Do you have experiences like this? I'd love to hear how you are handling this issue.