Conventional wisdom suggests that if a developer has estimated that a project should take 10 days then two developers working on the project together will take 5 days. However, it doesn’t work quite like that.
Many hands make light work, but every time you add a team member to a project you gain, at most, an average of 0.5 of their time on actual development (or gained 75% of their daily productive time and reduced an existing team member’s by 25%). Either way we’ve got 1.5 days completed work per day and not 2 days.
Given that we’ve estimated a project will take 10 days with one developer we should estimate it will take around 7.5 days with two developers and not 5 days.
It goes against your gut instinct, but when you add a new team member the following needs to happen:
- onboard the new developer to your weird project
- decide which developer is the lead
- decide who and how the team will now make decisions and communicate
- decide on git branching model
- review code of each developer
Onboarding
A new developer needs a bit of time to learn your project. Unless it is a very basic project, it will be hard for them to start making changes immediately. So you should always factor in a minimum of 0.5-1 day. This is because your project is weird. You don’t think it is weird because you’ve been working on it for X days already, but rest assured, 90% of the projects we encounter feature weirdness that takes time to understand.
Code written by and for one developer may not always be the easiest for another developer to come in and start working with. Does the original developer need to do any work to make their code easier to read? Have they kept their README files up-to-date?
So development work must stop or at least slow down for the existing developer to consider how the new developer will be able to start working effectively. The existing developer will also need to make themselves open to questions from the new developer once they’ve started. Once again, that slows down the team.
Who is the ’Lead’?
You now have two (or more) developers. Who is in charge and why? And if no-one is in charge, how are you explaining that to Developer A and Developer B? Developer A has worked on the codebase for X days and all of a sudden Developer B comes along and is their equal or their superior. They might not like that.
Communication
With one developer on a project they don’t need to be told which component/feature to build, or how. As soon as there are multiple developers you need to start planning who should work on what, what components should be named, in what order things should be built. Otherwise you end up with 5 different styles of ’button’ in your CSS and 3 React components called ’card’ and one feature being finished days before the next one is due because you assigned a small component to the quicker developer and large component to the slower one.
One project we worked on, were we were not in charge, had a component which 2 developers argued over and created competing versions of. This argument went on for weeks - for a component that should have taken 1-2 days to build.
Once communication is nailed, it can become a problem if Developer A and B become friends and chat a lot. Developer A can’t talk to themselves but, when you add Developer B to the team, all of a sudden there’s a new person to talk to about how much this project sucks ;)
Coding
You need to decide a branching strategy for Git. Maybe when you had one developer you coded everything on a ’develop’ or master branch, but with multiple developers you need a better structure than that. Developers need to make sure their branches don’t go out of date and don’t override other people’s work.
Code reviews
Once Developer B is happy with their code, they submit it for review via a Pull Request. Who reviews that? What is the criteria for approving/denying a review? What happens if Developer A doesn’t like the coding style of Developer B and they fall out. How do you plan to avoid that situation?
We’ve worked on projects where some developers don’t realise their reviews aren’t worded very nicely. And we’ve worked on projects where developers have argued in the review comments. A bad atmosphere can easily be created and time can easily be lost.
Making it work
The key is to factor in the fact that adding an extra person doesn’t halve the schedule. It helps but only a bit. That’s why throwing several new people at a slow project with a fast deadline can have the opposite effect - at least at first.
It’s a good idea to give the new team member a small feature to code. Maybe even one that never goes to production so they learn how the codebase works. Too many developers want to dive-in and start writing code on day one but it’s often a big mistake.
Sometimes you add Developer B and if they have worked with Developer A before on a similar project you may find everything is a little smoother and quicker, or you may find that after 5-10 days that Developer B is working so well and the team is working well together that productivity is now at a rate of 0.875 people days per actual day but, it’s rare to get it to a full 1 day per person.
Summary
Be aware that adding an extra developer to your project may not guarantee their full capacity for a while and factor that into your timelines.