You Don’t Know Jack! How Software Gets Developed Part III


Intro to Diminishing Returns

Side Diversion: Diminishing Returns

I’m sure you’re aware of the concept of diminishing returns, well this is true also in software development.

A classic example (extreme of course, all good examples are!) is that of the pregnant woman. One pregnant women will (typically) give birth in 9 months. If you add another woman to the equation, the baby doesn’t get born any quicker just because there’s another woman now in the mix. Same if you add a third woman, by this logic, the baby should be here in 3 months!

“But wait!” I hear you say. “Software development doesn’t involve splitting a fertilised egg between multiple wombs so they can do the work faster!” Of course you’re right and I’ve chosen a particularly ridiculous example, but the translation is apt, the only difficulty is that I’ve chosen something where the workload cannot be split (at least with current technology as far as I’m aware!). Any time you increase resources, generally you get a less than 1:1 increase in output. Diminishing returns isn’t only relevant for production, as an example this site will love, graphics cards!

As you spend more and more money going higher up the value chain of a graphics card, the returning performance you get per dollar you spend tends to decrease. Same again in terms of diminishing returns for adding graphics cards. The first card gives you 100% of its baseline performance. Adding a second card generally doesn’t double your frame rate, but will give you less than 200% of single card performance, the more cards you add, the less your incremental performance gain per card. Diminishing returns. It’s everywhere and it’s in software development too.

Factors to consider:

  1. Additional developers don’t just get magicked out of thin air to work at their desk. They need to be hired, trained, learn the project, learn the scope, learn the existing source code, learn the source code repository, learn the testing tools, learn the compilation setup, learn where the toilet is. Learn learn learn! Learning takes time.
  2. If you’re 5 or 10 people and you hire one new one, it’s pretty easy to get them up to speed. You sit them down, answer all their questions when they have them, teach them the basics and throw them at some introductory work aimed at getting them familiar. But imagine if you’re 5 or 10 people, and you need to hire another 250?
  3. Let’s say you’ve got your 250 developers and they’re working away and you want to hire another one. That’s another say $100k/year in costs, even if that additional person scaled in a 100% linear fashion (they don’t!), that equates to an extra 0.4% in output productivity. Diminishing returns again! When you were 10 people, that extra 1 gave you a 10% boost in productivity if they scaled at 100%!

Think 10 people have enough bandwidth to answer every question 250 new people have? I don’t. What about teaching 250 people everything about the areas of the source code they’ll be working with? That isn’t a quick job. How about interviewing to even hire 250 people? How many CV’s will you have to sift through? How many interviews will you have to conduct? How many offers will be accepted vs. rejected meaning you have to start again?

Simply put, scaling up is a tough job. It takes time regardless of what you’re producing. If it’s software, you need to get new devs, new computers for them to work on, new office space to house them, bigger internet connections to handle their traffic, bigger code repositories, new email accounts. Gah! That’s a lot of work. Adding a developer isn’t as difficult as adding another woman to the pregnant woman and hoping to get the baby faster, but the basic problem of scaling up your resources is still there.

So yes, adding money helps things, but in the event that you potentially change the scope of your phase one deliverable, it simply doesn’t scale linearly. Even if you didn’t want to change scope, adding more money simply doesn’t allow for added resource to scale linearly and you will encounter diminishing returns, more slowly at first, faster later.

As an example, I’ve had the joy in my career of needing to explain to my management that even though they are offering me more budget and developers to complete a given project faster, I needed to REJECT the additional resource I was being offered to if it was to be contingent on their new timeline requirement for the phase 1 deliverable. Have you ever heard of something so ridiculous as someone rejecting more budget and resource?!?! It’s not common, but in some circumstances it’s the right thing to do if it is attached to unrealistic expectations.

Keeping your project on track

The project was already on track and there wasn’t a huge amount of time for phase 1 left, adding more people at this stage to what were a couple of small development teams would only have slowed them down to the point where the net change in timeline for phase 1 was effectively zero since the new people would need to be trained etc and that training would be delivered by the people who are currently coding. Once the new staff were trained (assuming they were all reasonably effective at their jobs), they would increase the velocity (remember this term! More on this in Part V!) at which the teams were operating, thus catching up on most of the lost time. This would likely allow the team to deliver phase 2 and all subsequent phases ahead of currently projected timelines, but have no impact on the current phase.

Here, however is what adding money DOES allow you to do: Increase scope without having to ask for more money and in game development, that can be very important.

All of this of course leads us onto the general all important topic of MONEY!

Next week in part IV, we’ll look at budgeting!