How Many People Does It Take To Write Software

There is a joke that asks, how many programmers does it take to screw in a light bulb? First you need a business analyst, a product manager, a scrum master/project manager, an architect, a DBA, a designer, a QA manager, a release manager, a tester… hmm, did I forget anyone?

Yes, it's a terrible joke that I just made up.

Today there are a whole host of people involved in creating software in most organizations. Modern software development generally has a huge number of specialized roles, and often includes a large number of programmers as well.

When I started in 1981, most of those roles did not exist as separate people, in many cases we had only two: managers and programmers. The defense contractor I worked for basically had managers with programmers and managers who needed programmers. When I was assigned to something as a programmer by my manager, I was expected to do anything that was required from figure out what needed to be done to writing, testing and delivering—and often documenting—whatever it was. There was a concept of a programmer-analyst who did the first part but what I remember was we all did everything there.

Naturally what other companies did was a mystery—without an internet or any of the modern communications channels how other people did things was not known to us.

Having to do everything turned out to be a real benefit later on, I was comfortable with such diverse things as communicating with customers, designing UI, identifying and tracking plans, architecture, and other non-programming tasks. With today’s roles unless you are in a startup environment (sometimes not even there) as a programmer you rarely get to do anything but write code. People even joke about programmers doing other things like designing.

In the 80s programmers in general did a lot more things that today are all specialized. Of course we had applications with fewer moving parts like networking and databases, but we also worked without a whole lot of outside help, or open source, or any modern convenience like email.

Another difference was that huge teams were basically impossible to organize. Imagine working with 100 programmers on single application without email or Slack, code repositories, JIRA like tools and no way to coordinate software remotely other than Fedex and cartridge drives. Merging code between teams was a manual process–tedious and error prone unless you were really careful and disciplined.

My team actually did all this for Persuasion, we were in Texas and the author was in New York, we traded code via Fedex every other day for 8 months. Later on in the last release of Deltagraph around 1993 we did it again as the publisher in California added a couple programmers.

Today no one would build software this way. But today we also have the network, tools and processes to coordinate huge teams—but the cost is really high as so many different specialized roles have been created to support this. It’s funny how we’ve created so many tools today that would have amazed us back then yet need so many more people to get anything done.

Over the years I’ve always worked on small programming teams, other than the last version of Deltagraph in 1993 with 6 programmers, a project in the mid 2000s in Mexico that had 40 (and was a huge failure) 4 is the most I’ve ever done even large projects with.

Of course during the last few decades the non-programming side of projects has garnered an ever-increasing set of roles. It’s funny how we built Deltagraph with 4 programmers, 2 testers and a product manager, and built a product that lead its niche worldwide. Today at my job at a huge non-technology company (you would all know) we have 80 iOS programmers and more non-programmers and support people and managers than I even know. Yet functionally in the entire app (basically there are two similar ones) is not really that complicated.

The team I work for only has two iOS programmers now (we had three) and we built a large addition to one app with two programmers, ported it to a third business unit’s app, and built three internal apps during the same timeframe.

The Mexico project on the other hand had 40 programmers from three countries fly in every week to sit in one room in what was a death march. After three months the whole project cratered. The customer ran out of money.

At the travel company (two jobs ago) we also had a small team and managed to build and support 7 products with only 20 people total, half of which were programmers (4 iOS).

I still enjoy doing more than just take a ticket, work a ticket, PR some code, move a ticket to a new state—which seems the modern programmer role.

Today programmers don’t get the same “education” I got when I had to do everything myself—its something that you can only do if you get to experience it, which is why working at a startup can be really useful. From what I can tell that’s not always true though, often startups assume the whole suite of support people are necessary, and programmers do nothing but write code. If you have a lot of VC money I suppose it’s easy to spend.

Even with all the modern tooling and processes, from what I can tell enormous teams of programmers are very common today. At a recent conference I went to I asked people how big their mobile teams were, and having dozens of programmers was the norm. Uber has more than 100, I dread to think how many Facebook has.

What do they all do? I think the average programmer today writes very little shipping code every day compared to the 80s. I assume the norm is to write very little, write lots of unit tests, spend a lot of time in process and meetings. If you do these things you can’t get much shipping code done compared to what we could do back then when we had few tools, no email, no repository, no process other than what we came up, sat together and communicated by talking. We had much more time to contemplate what to build, how to build it, how to test it than most today; at least for my two companies (1985-1994) we generally had releases every 6 months or so. Since we shipped on floppies in boxes and had to charge people for a release you couldn’t release often.

Mind you we didn’t do Waterfall either, everything we built was done in an agile fashion long before it was called that.

Today people push software out through automated pipelines and release once every week or two. At my job we are lucky to release every two months due to a horrid process despite all the people. If you have a huge number of people who individually are responsible for little but are part of a large organized pipeline with automated testing you can get it out the door really fast, but it costs a lot of money and I am not sure that the end result is necessarily all that good.

I’ve usually worked in resource limited teams where we had more freedom to get things done, even in large projects, but never where the product shipped every week on a regular basis. Is the expense of large automated teams worth it? Maybe for some companies.

For me I would rather have a too small team that does more things for itself and needs fewer support people. I could not work in one of these 100 programmer turbocharged teams. It doesn’t sound fun at all either. I don’t know how to compare products built by 4 people taking time versus 100 people pumping out weekly.

I’d rather do a lot more things and take time to build a decent quality product and not spend a fortune. In the end it matters what is important to you and your company and what you can afford and how willing you are to organize a lot of people or else wait a little longer.

Are more people doing less with more organization and support people better than fewer people doing more individually? One can argue both approaches. I just prefer to be part of the latter.