Why Do Software Products Need So Many Engineers?

Before I started my most recent job, I explained to one of my former co-workers where I was going. I told him I was joining a team of 12 software engineers that was quickly growing. He took one look at the public-facing view of the product they had built and asked “Why do they need so many engineers?”

It’s a fair question. The two of us had just spent years building a pretty complex system to track people and equipment moving through physical spaces inside hospitals. We were on a team of 5 engineers. Why did this simple-looking web application require 2-3x more people?

This wasn’t someone unfamiliar with the tech industry asking this question. He was one of the best software engineers I’ve ever worked with! But I’ve heard similar questions come up a lot. My favorite one was when my friend’s mom asked “Didn’t they finish building Facebook years ago? Why are they still employing people?”

For the question about my upcoming job, I didn’t have a great answer yet. I knew there must be some underlying complexity that I wasn’t thinking of. I just hadn’t thought too much about it yet.

After almost 4 and a half years going deep down this rabbit hole, I finally have an answer.

What the public sees

The application I worked on was a restaurant reservation and management system. I’ll be using restaurants as an example throughout this post, but the same principles apply to other booking systems (hotels, flights, salons, etc).

Let’s look at a core piece of the public-facing product. You select a restaurant, date, and party size. Then, you choose when you want to dine.

In this simplified example, the restaurant is open for dinner from 5-8pm. We display times within that range at some interval. You click a time, fill out some personal info, and now you have a reservation. Pretty simple, right? Many programmers could build this in a day.

Unfortunately, this isn’t how restaurants work. They’re not magical places with infinite capacity. They’re constrained by their physical space, their table configuration, their staff, and many other real-world factors. Just because a restaurant is open when you want to eat dinner, it doesn’t necessarily mean you can make a reservation for that time.

We don’t just need to show when the restaurant is open. We need to show when the restaurant has space for 4 people.

As a diner wanting to make a reservation, this looks like a trivial UI change. It’s just a slightly different color and some added text. But from a product perspective, this just got at least a thousand times more complex. Let’s dive into this a bit more.

Physical constraints

To figure out which times are available, we essentially need to know the capacity of the restaurant and then subtract the reservations that have already been made.

That doesn’t sound too bad, right? If the restaurant can hold 100 diners and 98 have a reservation at 6:30, we clearly can’t accommodate a party of 4, so we need to show it as “not available”.

Not so fast. That simple strategy would only work if the restaurant had 100 individual tables that each seated a single person. This also assumes that nobody stays longer than 30 minutes. That’s obviously not how restaurants work.

Restaurants have tables of various sizes. Let’s say a restaurant has two sizes of tables: small tables that can seat 2 people and large tables that can seat 6 people. A reservation for a party of 3 is essentially taking up 6 “spaces”.

So now we need a way for the restaurant to build out their table layout. That alone is a huge undertaking, and it’s completely hidden from this public-facing view we’re looking at.

Once we know about all the tables at the restaurant, we’re still not even done with this bit. Consider that some tables are fixed in place and some can be pushed together to make a larger table. If a party of 10 wants to make a reservation, you can push 3 tables together to accommodate them. So now we need a way to configure which tables can be combined.

Diner constraints

Even after we know the table layout, we have to deal with the fact that most people don’t eat for 30 minutes. A party of 2 might stay for an average of 1 hour, but a party of 6 might stay for an average of 2.5 hours. So a reservation at 6:30pm isn’t just blocking off space for that time, it’s blocking off space for future times as well. We need a way to configure all of this based on how long people tend to spend at the restaurant.

So now we know all about our tables and how much “space” various parties take up. We’re still not done with our real-world constraints.

Staffing constraints

There’s only so many diners the host, servers, and cooks can handle at once. You don’t want 100 people showing up exactly at 7pm even if they could all theoretically fit. The kitchen can’t handle cooking 100 meals at once. So we need to spread it out. Even if there’s space in the restaurant at 7pm, we might want it to show as “not available” so we can push more people to come at 6:30 or 7:30.

Exploding complexity

I could go on forever about the constraints our system needs to know about. The patio is open during the warm months, and there’s less capacity in the cold months. The restaurant might want to hold some of the best tables in case a VIP wants to make a last-minute reservation, but open any empty tables to the public within a given timeframe. Etc, etc.

Each one of these constraints involves talking to restaurant operators, understanding their needs, monitoring usage, and continually improving the system. Making each of these constraints work together with each other makes the complexity explode in ways you can’t imagine until you’re deep in the weeds.

That’s why many simple-looking products need so many people to build and maintain them.

In every industry, there’s a whole mess of constraints that 99% of people don’t think about. Good software hides this from them. To the end user, tens of thousands of product development hours often get distilled into a slightly different colored rectangle.