That's why more developers aren't always the solution

Faster way to launch

The scenario is well known: the solution you want should have been launched yesterday. You know that time is getting tight, but this time you have a bigger budget. Isn't it just putting on more developers to get this in port ASAP?

We meet this expectation often. The reality is that it is often the opposite. More developers can make the project run slower, especially towards the end,” Vladimir says.

The more, the faster?

It may seem counterintuitive, but the phenomenon is actually so common that it has been given a name. Brooks' law is called that in the developer community, and Vladimir explains why it is so.

Adding manpower to a late software project makes it later.
^{‍Brooks' Law}

“It takes time to move resources, adjust the flow of information and conduct training. In addition, with more people, you will also find more bugs. That's good, of course, but then it also passes with more time. You could always just launch, blissfully unaware of what bugs exist, but as soon as you know about them, you have to fix them first.

Vladimir sums it up with a quote by Brooks: “Nine women can't make a baby in one month.”

Of course, it's natural to want things done as quickly as possible. But bad time, no matter how many developers you have, will go beyond quality. And what is cheap can quickly become expensive, Vladimir points out.

Want to know how cheap can become expensive? Read the post with Vladimir here!

Could be better

What Brooks' law lacks, according to Vladimir, is that quality increases by the number of developers. Of course, it's not always a bad idea to have a big team.

No, and especially at the beginning, it is advisable to be more. Especially if they're in sync and work well together. Then you get the project kickstarted,” explains Vladimir.

He himself is a big fan of being multiple heads, given that they work together from the start -- and have sufficient time.

“I like to gather a lot of opinions into a project, and to have people to spar with. If we have that, and carry out the project at a reasonable pace, it is also easier to go back later and further develop the solution,” he says, adding:

So the challenge comes when you add more developers late in the race. It can work fine if you set them for example only for documentation, but even that will slow down and thus lengthen the time.

This is what you should do

Vladimir's best advice is to ask for help earlier. It's not like you need to do the preliminary work all by yourself.

“We can help you already in the planning phase, providing you with resources and ideas as we estimate. This sparring helps give the project a steely course,” he says.

He advises everyone to start from the quality they want. If you want something to be really good, it doesn't help to have a big budget if time is too short.

“Time pressure is the worst thing for developers, and therefore also for the end product. Therefore, get out earlier than you think is necessary. Then the result will be the very best. Unfortunately, people often reach out when it's already a little too late,” he says, concluding:

One of the saddest things I know is amazing ideas that would have deserved more time.
‍^{Vladimir Janjušević, developer at Increo}