Will we be faster if we’ll have an extra developer?

This week I was asked a really difficult question: Are we ready sooner if we'll have a new developer?

Before exploring this any further I would like to mention that the question itself tells something about the asker. Instead of assuming that of course adding a new developer will make the team faster, the asker was aware that especially in software teams this isn’t always so. There’s even a risk of the opposite.

Nevertheless, we had to make the decision because we are in the middle of the project that is running out of time. The cost of the delay is quite big and we already have used many other tools for meeting the deadline, including reducing the scope heavily. Before I tell you what our decision was, let me explore the advice I got from the precious Twitter from my precious friends.

1. Ask first the opposite question

First of all, Torbjörn Gyllebring gave this excellent advice (read the second sentence):

I think this a great starting point. If your team would be actually faster by making it smaller, then it obviously won’t be faster by having an extra developer. I’ve been in a team having 13 developers (incl. a tester) at some stage an losing some of them didn’t make us any slower. And it wasn’t about getting rid of the bad developers. For every team there is an optimal size, which isn't "the bigger, the better".

Anyway, getting back to our current project. This advice didn’t help us because we already had a small team and removing someone would probably slow us down.

2. How well is your problem understood?

Now read the first sentence of the previous tweet. It might be that the structure of the problem is such that scaling is unfeasible. This resonates really well with me since couple of weeks earlier the answer would have been definitely "No". Our biggest challenge in the beginning of the project was to understand what we were actually about to do and especially how we should do it. The domain in a high level is quite easy to understand but the details are not. Besides we are heavily dependent on underlying systems, and the integration flows aren’t really obvious.

However, when the question was asked, we already had solved the biggest problems in this area meaning that we knew what kind of code to write. So neither this comment helped giving the answer.

3. What is your current codebase like?

The next good advice was related to the quality of the codebase:

I think that this too is a valuable advice because the quality of the codebase really affects how fast the new team member can start being productive. A crappy codebase can mean that the developer needs months in order to become productive. In a good codebase that can happen within days.

Luckily our codebase is really young. Or to be precise, we are extending an existing codebase but the features we create are completely new and I would say that at least 95% of our code doesn’t touch the existing one. So neither this prevented us taking an extra developer.

4. How good is the potential developer?

One of the advice I got on Twitter was related to the skills of the new developer. It is actually pretty obvious that the skills matter a lot. If the new developer just started coding last year, she probably won’t be very valuable if the other team members are much more experienced. In such a case the team probably requires certain level of quality and guarding that may take the precious time of the experienced developers.

But even though you’d be offered a senior developer, how could you really know her skills? We can read her fancy CV but due to the critical deadline there’s not too much time to spend on interviewing or testing the developer’s skills. What helps in this case is really simple. If you know the person beforehand, you don’t have to spend your time on that. And now we are very close to our decision…

5. Can you have a developer that’s already familiar with the system?

One of the developers in our team suggested that we could borrow a developer from another team close to our project. I really liked the idea because besides we knew his skills, we knew that we don’t have to spend too much time on teaching him. And that was our solution: we’ll be faster if we can have this particular person. An hour later we were told that he will start the next day.

Formula for selecting the answer

If we collect all the advice together, I think we have a decent formula for defining whether an extra developer would make the team faster:

1. Make the sanity check first - would removing one developer make you faster? If yes, then forget the new one.

2. Is your problem understood well enough? If not, don’t try to solve a wrong problem by getting a new developer.

3. What is your current code base like? If you don’t have too much technical debt, you might be lucky.

4. How good is the potential developer? It also helps if you know the person beforehand.

5. Can you have a developer that’s already familiar with the system? If you can, your chances increase.

I think it’s important to notice that all of these questions are somehow related to time. The questions 3-5 in such a way that you need to have more time in order the new developer to make the team faster. The questions 1-2 so that if you first solve some other problems, maybe later you can have the benefits of an extra developer.

What if I still cannot answer the question?

It’s easy to admit that the formula above isn’t very exact. Maybe I should rather use the word guidelines. Anyway, it might be that your problem domain is probably clear enough but you are not sure. Or that the developer probably is good enough but you are not sure whether she’s good enough taking account the time you have. And so on. In that case assuming that your cost of delay is big enough - meaning that wasting money for an extra developer isn’t issue as long as she won’t make the team slower - you probably just have to do what Vasco Duarte suggested:

There are things that you can only find out by trying. On the other hand, you may want to mitigate your risks. If the lost money isn’t the biggest issue, the biggest risk probably is that your team will get slower. This could be caused that the other (fast) team members need to spend time on helping the new developer. One possible solution for this is to throw the new developer into the cold water. If she can swim alone, she probably will be helpful for the team.

How about your team?

So here are my questions for you. If you were asked the same question, what would you answer and why? Would you have an extra developer? Would you make the decision based on the advice above or use some other ways to decide?

PS. I started this blog couple of months ago. Thanks for all the readers. Next year I will continue with the same goal as this year: one blog post per month. Merry Christmas and Happy New Year!