Why you must never add resource to a late software project

Never add resource to a late software project…

Many of those new to insurance software development assume that adding programmers to a late project is the right thing to do in order to finish as quickly as possible.

WRONG! This is almost always the absolute worst thing you can do. It will not only not help but will actually make things worse, often much worse. You’ll probably never work in software again.

Why?

The reason for this is simple: communicating software ideas on even the simplest project is frightfully expensive and rises exponentially with the number of team members.

In our industry, even the most elegant insurance software is complex at its heart.  We deal in increasingly complex mathematical and emergent algorithms; we can’t get everything across in a single utterance, this is actuarial science.

With each developer you assign to a project (at any time in its lifecycle) you increase the vectors of communication, often considerably, and the average communication burden for each team member goes up.

To explain more clearly…

A 1 man team communicates within her head, so no problem there.

In a 2 man team, there are two vectors for communication. When Hildergard (eh?) writes code that Bartholemew (who?) doesn’t understand, he interrupts her flow to ask about it, and visa-versa.

In a 3 man-team, there are 6 vectors for communication, whilst in a 5 man team, there are 20 vectors for communication. When Jonah writes a new routine that he wants people to use he tells the team leader Archibald. Archy tells everyone to refactor their code to use the new routine but they’re all very busy, and it’s not the first time someone has told them how to make their lives harder. Consequently, many of them forget, realise too late, can’t even remember where to find the routine or how to use it, or never took their headphones off in the first place. Consequently, sporadic conversations break out between all team members: Jake and Ben talk about optimisation, Phil and Lindsey argue about nomenclature, Ben and Lindsey agree that Roger, Jake and Derek have usage all wrong. In the end everyone speaks to everyone about it, and after all the chinese whispers subside, Jonah wishes he was in a 1-man team like the good-old days: no one has used his panacea routine properly and some not at all. Now he has to rewrite everything, and hold a mini conference to sort things out. Again. Just like yesterday, which was his birthday and nobody remembered. Jonah decides to cut his losses and quits.

The Theory

Fred Brookes (the immortal God of software development theory), defines the number of vectors thus, where n is the number if developers on a project, and v the result:

v = n(n – 1)

So, with a 6 man team there are 30 vectors for communication, and with a 10 man team *gulp* there are 90.

So what?

When you add techies to a late project, you screw everything up. Software development isn’t like building a house, it’s much more like designing it, only harder. Let’s say you add 2 people to a 3 man team, right at the end of the project. At this point your programmers are working day and night, sleeping under their desks and eating with one hand. The team leader is living and breathing code, has a caffeine drip and never stops muttering to himself in binary. He’s getting email questions every second. That’s when you choose to increase the chat traffic vectors from 6 to 20 and bring in a couple of clowns who keep asking stupid questions. And when they finally do some real work, they bring the whole precious house of cards fluttering to the ground. What you’ve done here is invite a couple of wet monkeys in to dance on the architect’s blueprints.

You pay peanuts…

The thing is, even programmers sent by God Himself[i] need things explaining if they’re new to the project, and even then they still screw things up for a while (a year usually). That’s even if you have great documentation (and you all obviously have that… right?).

You can actually make the project go backwards.

What?! Yes, if you get a situation where the team doesn’t have time to explain everything to the newbie, he starts guessing, and changing code he doesn’t understand.

If your poor junior is left to work on rating matrices or something that affects billing or reports, you can kiss your insurance operation goodbye. By the time you find the bugs, it might be too late.

Holy cow. Whatever will I do?

  1. Don’t add programmers to a late project (well yeah).
  2. No really, don’t ever do it.
  3. Study software development theory: start by reading this and this and this.
  4. Set realistic deadlines (easier said than done – more on this in a future post).
  5. Encourage group communication; ever heard of scrum? It’s important to have well organised, poignant, productive group discussions.
  6. Expand your software ambitions horizontally. This means putting new programmers on new projects, creating complimentary projects that all work perfectly and get finished on time. Wise men know nothing can be done fast. It becomes another thing entirely when done differently, faster. Piling resource onto something you want done faster than it can be done is silly vertical horseplay, it will end in a heap of burn outs and angry developers who no longer trust you.

Show me the money. What’s the quick way?

Hmm, there’s no pleasing some people. Well you could always take a leaf out of Google’s book: buy your programmers pizza, make the vending machines free, and give everyone a share in the profits. Make the office so friggin’ cool they forget where they live. Take all the door knobs off and put in a disco ball. Never run out of coffee.

Did you like this post?  Leave a comment below…


* Like Einstein said, _He_ doesn’t play dice. God built the world in 7 days with C++. Being perfect, he has no need for managed code.

Photo by jurvetson

One comment

  1. Fred Brooks (MMM): “9 women cannot make a baby in 1 month”

    Great article and I concur 100%.

    For 11 years I worked as a consultant specializing in recovering, rebaselining or closing down late projects across a plethora of markets. Educating senior and executive management why adding resource to a late project increases duration and team complexities and less gets done.

    I think many senior managers and executives think of software development in the same context as manufacturing widgets and moving them off of this paridigm is one of the biggest challenges for PMs.

    Go Agile!

Leave a Reply