How Many People Does It Take To Ship Software?

There are a million jokes along the line of “How many _____ does it take to screw in a lightbulb?”

Sometimes I laugh at work at how many people are involved in the project I am working on. We have me and one other programmer and 20-30 other people that we can count for a three month or so project. This is after about 6 months of creative approval cycles with an uncountable pile of VP’s; yet changes keep happening despite all the requirements for deciding everything in advance. On top of that it is not too dissimilar to a project done by a different team (though the code is not reusable) that is about to ship.

Why so many people? It’s a mystery why bigger companies have bigger teams to build things that are not so big. I’ve come to the conclusion that the more people you put on a project the more people you need to manage the people you put on the project plus the people needed to manage those people, and so on. “The bigger the team the bigger the team the bigger the team.”

Back in 1988 we built Deltagraph which wound up leading its market segment (chart/graphs for print) yet the entire team was 4 programmers and one QA on my team, and the publisher had one QA and the product manager. That was it, and for an application that was similar in size and complexity to Excel by 1993. Eventually the publisher added a couple more programmers on the last version we worked on.

Two jobs ago I worked for a brand name travel company (now sadly just a brand of someone else) with around 1,000 or so employees worldwide. Our mobile team had about 20 but by the last year we had grown to 15% of the gross revenue and if we had continued would have been 20%. We supported 7 different applications (native and web) and a mobile API between us. We had QA, a product manager, designers and programmers mostly in one place and one manager to rule them all. Our API and web apps ran on AWS which we managed ourselves. The rest of the company had one product (the main web app) in the US and one in Europe. We averaged 70-80 releases of things every year and the main web app barely changed a couple times a year.

I talked previously about one app we built in two months with few people and not even much of an idea what it was going to be.

When I worked as a consultant (not contractor) fixing customer’s problem areas I often worked by myself being analyst, project manager, architect, programmer and DBA all at the same time and often I had to design non-computer processes as well. I remember working on a large project for nearly a year with just two people doing everything.

Some times I am amazed when small startups crank out amazing products with hardly anyone and little management but since I’ve been there I can at least imagine it. I’ve always thought that the smallest possible team can accomplish great things, provided they are in control of how and what they are doing. Usually in big companies you wind up with everyone wanting to control everything, massive division of labor into small slices of responsibility in order to let many teams have a piece of the pie.

The more people you have in any project the more communications you need, the more management you need, the slower information is disbursed and problems reported. You have to have more process to ensure that anything will be accomplished. Of course this all costs more money and time and often you have to do less just to get something shipped. It’s easy for everyone responsible for all these people to worry about unknown problems biting them in the ass so every decision becomes very conservative and cautious.This of course makes shipping difficult, expensive and often drags things out for a long time. Add to that memories of previous projects that had the same issues and things get even more cautious and slow.

Compare that to small startups who aren’t held back by caution, heavy process, siloed management and worry. Even our travel mobile team was more than willing to take risks, to use small teams and try new things like AWS instead of building empires despite being part of a large ponderous entity. It can be done in such an environment: this team started without any support from anyone as management just wanted mobile to go away and assumed it was a fad, which made it possible to stay lean even as we brought in more and more revenue.

Look at any government project and you can’t help but laugh at how many people get involved in everything. I remember at the consulting firm I worked for, two of the guys had worked on a DOD project involving some kind of healthcare initiative where they were 4 or 5 levels of sub contractors down from the primary contractor; they often had no idea what was going on or what they had to do. The recent laughter at the $350,000 app for the TSA which was nothing more than two arrows and a call to random() was an interesting example. One place I worked as an architect had a project I estimated at 2 person-weeks of coding. Six months and dozens of meetings later to write a 120 page requirement documents resulted in the same estimate. We could have built the app 10 times over. But what would all the people at those meetings have done?

I have coworkers who rarely get to write any code and they are pulled into so many meetings and calls they barely qualify as an engineer any more. The time spent coordinating and explaining and planning and scrumming and preparing for more of the same leaves little time to actually deliver anything.

Thankfully for all of my 35 years as a programmer the only large team project I ever worked on was three months in Mexico in a real death march that never went anywhere. I’ve stayed away from anything otherwise I can’t count with my fingers. Sometimes you need more people and more planning like building an OS but most of the time fewer people is always better, again provided those few people can control how and what they are doing. You can’t use minimal teams and then pile on process and standards and reporting and meetings and the like, and expect the few to make it work.

Even once the code is done at my current place there are multiple teams who have to meet and approve and fill out forms and coordinate and get sign-offs from various VPs in order to push anything, even to test environments. It’s insane how much process there is. I imagine there are many places out there that are no different or even worse. It does provide for lots of employment.

I am also sure that many people feel that all of this cautious complexity is necessary, or at least it makes higher management feel more secure. Some of this may be necessary sometimes (I haven’t ever written code for a nuclear plant) but given all the projects I seen with large teams most of them never really justified all the reams of people that were involved.

You can never know what you would have accomplished if you had had an extremely lean team with a lot more freedom in how they went about doing the project but often companies don’t want to take the chance. Building empires of people with narrower and narrower responsibilities gets more people involved and makes the leadership feel important. Do you really need creative/design, animation, copy, project management, product management, delivery management, development management, promotion management, operations, DBA, various levels of QA and others I don’t even know plus several layers of VPs to ship the work of two programmers?

I bet you really don’t. I miss the days when the team was small but the results were big.