I’ve been involved in projects of all sizes. My focus lately has been on smaller prototyping and proof of concept demonstrations with as little as one or two people, but I’ve spent years on large projects with hundreds of engineers.

There is a problem that shows up again and again in a wide range of projects when you get above a certain size. The problem is premature parallelization, which I touched on in the last post about pair achitecture. The surprising thing to me is that I’ve seen it be a problem with just half a dozen people.

The problem comes about primarily from a pressure to execute. If you have a team of architects, you want them architecting. If you have a team of developers, you want them developing. When a new project or feature comes along, there is a drive to get everybody engaged as quickly as possible. The thinking seems to be that, by engaging everyone as soon as possible, the work starts sooner and therefore the work will get done sooner as well. In a way, it is like a horse race - all the groups lined up in their starting gates chomping at the bit in anticipation of the starting gun. What gets lost some times is the up-front collaboration work required to make sure everyone is really pointed in the same direction and everyone knows where the finish line is.

From what I’ve seen, the bulk of this pressure gets directed at requirements and architecture activities. For development to start, there needs to be an allocation of requirements to hardware and software components and that job typically falls on the architects or system engineers. The number, organization and relationship between those software components will drive the staffing and organizational layout of the development teams. So development managers get antsy and want to know what work will be coming their way. One common response is to “loan” senior developers to help the architecture activity. On the surface, this is a great idea. It enhances communication, which is what software development is all about. The additional resources theoretically make the architecture activity finish faster.

But sometimes the worst thing you can do to a problem is throw too many people at it. Communication can get bogged down with too many people. And with too many people, the architecture activity gets pressure itself to parallelize. Different people are assigned different areas and different document sections. Then, like race horses with blinders on, they work on those areas as fast as they can. Without adequate collaboration, they generate inconsistent work products that cause real problems later on. Hopefully the fallout is limited to a long, drawn-out review process that finds most of the inconsistencies. At worse, it is a problem that doesn’t get identified until system test or deployment.

Having been more involved with smaller group activities lately, I’m much more inclined to start with a core team as small as possible and work a number of iterations to come to a common understanding of the problem and a common general idea of how to solve them before growing the team. A close-knit team, with a common vision and a partially validated approach provides the best foundation for growing the team and expanding development activities.

Of course, the devil is in the details. How many people do you start with in the core team? How do you know when to bring in more people? When does idea validation start slipping into product development? When do you consider adding contractors and/or interns (frequently an issue for my current group since we don’t have many dedicated developers)?

I don’t have any guidelines. I know what it feels like to be in a small team that clicks and starts making rapid progress. I also know what it feels like when ideas are concrete enough that I know growing the team will increase productivity. And I know how frustrating it is to have too many people involved when those ideas aren’t crystalized. I also know how resistant people are to throwing out ideas once they have some inertia, even if they aren’t proving out to be good ideas. But I don’t have a standard formula for how to grow a project.

I remember a manager telling me one time that we had joined the “million dollar a day” club. In other words, the project had grown so large, development costs across all prime contractors and subcontractors totaled a million dollars a day. Nothing starts that big. But you can’t get anywhere close to that without parallelization. Productivity requires a divide-and-conquer approach. But doing that too soon is a sure way to sidetrack your project.