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

Advertisements

Deciding it for yourself

If you can’t let the developer decide, who should make the technical decisions in your organisation then? Unless you’re technically skilled, and you happen to know a lot of software development theory yourself, deciding which components to use yourself, is arguably the equivalent of playing Russian roulette with your organisation. Facts are, some 3rd party vendor could probably have waved a beautiful website in front of your face, and you’d happily buy something having zero value, believing in the company’s spiehl about their product’s superiority. Obviously this doesn’t work either.

What you should do, is to align yourself with somebody having the knowledge required, but no incentives in regards to increasing your technical debt. Somebody who have incentives that are aligned with yours – Then you should “outsource” technical decisions to this individual or organisation. This might be a person you employ, for instance a “super duper senior” developer, that has already reached the point, where he have few things left to prove. Or it might be an external consultancy company, that is neutrally assessing components, without any ties to the vendors creating the components they are assessing.

Doing a StackOverflow search, only results in finding whatever tool happens to be most popular at the time you are doing your search, and speaks zero about quality – Since components happen to suffer by “networking effects” – Which implies that adoption speaks nothing about quality, since developers tends to gravitate towards whatever is the most popular component, realizing this will give them a larger chance in the job market to find a better paid and more interesting job later down the road.

You can still have the most intelligent individual making your (technical) decisions, just make sure his or her incentives are aligned towards your first, to avoid experiencing the Cobra effect!

That way the dog wag its tail again, and the inmates are no longer running the asylum

Leaving it for the developer to decide

Most junior and senior developers have one simple incentive; Investing in their own future. The way they tend to do this, is by acquiring more knowledge about potential things they imagine future employers will be interested in. This way the developer makes himself more valuable to any potential future organisation and employer, until he reaches the point that he has made himself indispensable. This creates a problem, which is that the developer’s incentives is in direct competition with his employers incentives. In fact, the incentives are arguably aligned in completely opposite directions.

At the same time, the employer is 100% dependent upon the developer’s opinion and advice, because he is the only one adequately equipped with the knowledge required to make choices of technical nature. This results in a “wag the dog” situation, where the most capable individual to be making a decision, is also the least likely individual to be making the correct decision.

For instance, if you ask an average developer how he feels about some component that solves some specific task, he might find the challenge of creating a similar component more intellectually challenging than simply reusing something existing. This might result in that the developer will be looking for flaws in the component his employer asks him to evaluate, in an effort to discredit the component, trying to convince his employer that he would be much better off letting the developer implement a similar component for himself. This would be in alignment with the developer’s incentives, which is to make himself more valuable.

The expression “wag the dog” implies that the tail wags the dog, instead of having the dog wag its tail. Similar expressions have been made that are of more explicit character, such as “the inmates are running the asylum”. Regardless of how you look at it, if you let the developer alone to mind his own business, he’ll probably do what’s in his own best interest, which is to accumulate more technical debt on behalf of his employer, happily coding away, one line of code at the time – Until the cognitive overload of the organisation as a whole, is so large the organisation can no longer sustain itself.

But why should the developer care? He already have 20 new job offers at LinkedIn, which he now is far more likely to be able to fill, due to that he’s learned all those new and shiny things, while breaking the back of his current employer.

Congratulations, you’ve now entered the “wag the dog” world, happily allowing your “inmates to run your asylum” – You’re no longer in charge of your own organisation, because you allowed your “most competent individual” to make your decisions

This will probably come as a surprise to you, but allowing your most intelligent resource to make the most important and hardest technical decisions, will only result in more intelligent objections against using the most intelligent solutions.