Adding more developers to an already late project

This is a variation of the Mythical Man Month, and probably equally unintuitive. However, the research in this area is bulletproof and has been verified thousands of times by independent researchers, and its conclusion is “Adding more developers to an already late project only makes it later.”

The reasons of course includes that you’re forcing your only productive resource to spend precious time teaching the new developers to understand the existing codebase, in addition to that now the project requires overhead, coordination, and collaboration, adding to its overhead – So while you believe that you’ll be able to finish faster, the exact opposite is the result.

If your job is to move 1000 bricks from A to B, and you’re late, adding more manpower to the job obviously results in finishing earlier. Hence, human experience have taught us that adding more manpower to a job, results in finishing the job faster. Therefor, when a manager is faced with the prospect of not finishing the software project in time, his intuition is to add more manpower to the job. However, you’ll only make it later. Understanding this though, and believing in it, requires huge amounts of experience – Experience most software development managers don’t have. In addition it requires courage, courage to say “NO” when your investors and CEO are telling you to add more resources to your team. However, a mature and experienced software development leader will easily be able to explain this fact to his managers, allowing for the project to finish as fast as possible, without adding to the cognitive load of his team, by adding more manpower to an already late project.

There exists many reasons to hire more manpower, but making the project faster, is not one of those

Mythical man month

Of all the concepts I have ever tried to explain to non-technical management, the “mythical man month” is probably the by far most unintuitive concept. The ideas behind it, was thoroughly researched already back in the 1960s, and several books have been written about it, in addition to that hundreds of independent scientific studies have proven the theory to be correct – Still it seems like almost impossible to believe in for most non-technical managers.

When the idea was first coined, the man behind it, who was a computer scientist working for IBM at the time, even wrote a book by the same name. The book is fairly long, and enters long arguments, trying to justify its existence – But the idea can be summed up with a simple sentence. Please read it several times to make sure you understand it …

One system developer can do in one month what two system developers can do in two months

Yes, you read it correctly – At least I hope you did. Hint; If you weren’t surprised, read the above sentence once more. It’s almost like “black magic” when you think about it, but the theory have been proven to be correct thousands of times since the idea was originally coined. The reasons are complex, and includes a lot of esoteric and unavailable understandings, such as communication overhead, coordination requirements, integration problems, lack of cohesion, and lack of tranquility – But believe me, the idea is as sound as gravity.¬†What the idea basically implies, is as follows.

One software developer could easily replace Google, while 200 software developers could never do the same.

And in fact, we’ve already seen this in the real world, in the form of Mark Zuckerberg, who arguably is (yes he actually is) a mediocre software developer. But the most famous example of the theory is Linus Thorvalds, and I don’t mean because of his “Linux thing” – Nope, I mean because of his “Git thing”.

When Linus needed a scalable software versioning system, he looked around, and investigated CVS, SourceSafe, SubVersions, and practically all other versioning software systems that existed – Only to conclude with that they were “all rubbish”. At this point in time, approximately 20+ million software developers had been working with some sort of software versioning system for approximately 70+ years – Leading you to believe the problems should have been solved decades ago. But no, this wasn’t the case – At least not according to Linus.

So Linus took “vacation” from maintaining the Linux core, and spent 10 months implementing a software versioning system. Today you know this system by the name “Git”. Today most developers without grey hairs can’t even remember the alternatives, but believe me, they existed. Yup, I’ve gone through SourceSafe, Microsoft Teams, SubVersions and even CVS – And Linus Thorvalds was right; They’re all rubbish!

In 10 months one single software developer, created arguably a software versioning system revolution, resulting in changing the daily routines of 26 million software developers, in 300+ countries on the planet – And he was alone, and he spent no more than 10 months!

Let that simple fact sink in for a while please …

Now of course, Linus is not “just another developer”, but that’ll be the subject of another blog …