Don’t over-hire developers.

It was a cold night, I was seated in my programming chair, at around 11 PM, I had just completed a team meeting regarding an upcoming release. I was one of nine developers working in the team. It was a peculiar “We will check it out.” call where for some reason, everyone was ready to address an issue only in the future.

I had been working with the startup for over ten months, I had started as one of the “Interns” they had hired cheaply to get some additional work done, but it turned out I was the one getting a majority of the work done. The first two months were amazing, there were only three developers in the team, I was getting a lot of things done every day as I ticked box after box of a new feature to be implemented by me or things to be worked on by me.

At the pace we were progressing back then, the product was supposed to be ready in less than two months. The other two developers, however, were the ones who would respond “I will take a look at it.” to every bug, every feature or everything you threw at them.

Past the end of the second month, I started noticing stretched times where I would be sitting idle because I would be blocked by the work someone else had to complete, on which my further work was supposed to be based on. Over the next one month, it started happening more often, at one point, I was sitting idle for days on end, so much so that in the middle I started looking for other opportunities I could take up to fill the time that was being wasted in between.

Before I did that, I wanted to know the reason that why the other developers, even after being proper employees of the company, were taking so long to get even the most basic things or changes completed. (By basic, I mean the code deployment to change the structure of one API response from one to another.)

Turns out the other two developers, even though were called employees, were technically not employees. They turned out to be the people that had a primary job and were here for no pay (They had been provided with a share of the company) in hopes that the product they were building would someday pay off.

Not everyone is going to work

A rule of thumb for a software team is that there is going to be one developer who is going to do the work of four other developers. And similarly, there are going to be four developers that would be equivalent to one or half a developer.

There are many reasons for this, sometimes it’s the developer’s state of mind (A developer not happy with life, in general, is not going to be great at work, even though he might have the potential to be the defining member of the team), sometimes it’s the developer’s priorities (They prefer to not put much effort into the work they do and are doing it just for the paycheck at the end of the term.) and more often than not, it’s the fact that they have work elsewhere to get done.

In the software engineering world, it is not uncommon for developers to be working on three things at the same time, one main job, one side job and one personal project. I did five things at the same time at my peak (Which includes College, although I don’t recommend anyone this considering it is a severe mental strain to do so).

Why the above might be a problem is discussed in the section regarding Moonlighting.

How does hiring more developers lead to

Blocking from one is a blockage to all

If the event of you having to wait for other people to get their work done so you could start working on something sounds familiar to you, you know what I will be talking about in this section.

As I explained in the previous sections, I have had to sit for days or even a week doing other stuff while someone finished the one-line change required to do something. Now you might be asking “Why didn’t you just go and fix it yourself if it was that easy?” and the fact was I did multiple times after I got hold of the code required to be changed once.

It is very very usual for software teams to be stuck in such deadlocks. The thing is, the more the developers, the faster the communication between the team members breaks, the more wasted effort there is and the more the deadlocks originate.

Communication becomes a problem

With almost eight members in the development team, the management decided to have a daily standup call where everyone was supposed to tell what they are working on and what is blocking them, and use that call as a place to resolve any questions or blockers they may have.

Anyone who has been in a poorly managed team where the rules of attending calls are not strictly imposed knows that not everyone shows up on the call. Hence, there is wasted time explaining the things that happened on the call to the people who missed it and hence there is a chance that something might be left out in the details that turn out to be the deciding factor in one team member wasting several hours working on something that is not required.

There is software that is meant to solve that issue, there was software that the management paid for that recorded the calls and added the transcript and recording on a slack channel.

Now, that’s great but due to that nobody showed up for the calls in the first place. Also, the purpose of the call was not being fulfilled considering people were not joining it in the first place, hence someone could not communicate with the team members when required.

The team resorted to then run on faith and direct messages to the person responsible. Which as you might know working with teams where people don’t have the right incentive to work, does not work.

Moonlighting is great, but it kills the company

I am big on part-time work, it’s a great way to earn money and keep options open around, and also know a lot more than what you can learn by just working at one place. Because of this reason, I often don’t work full-time for anyone, because full-time employments often require that I don’t work with anyone else, plus if I commit to full-time employment, I usually wouldn’t have the capacity to focus my attention on both.

When full-time employees begin to seek outside work, it starts to become a problem for the company that is employing them because their focus tends to be divided, and hence, the company often tries shelling out incentives to get things done, or worse yet, tries hiring more developers.

You don’t need many developers in the first place

Most of the startups I have worked with, I was many times the only or one of two developers working. And guess what, we still got almost everything done on time. When Instagram had millions of users, it had less than 5 engineers. Software is something that requires a great architect and a great coder, most of the times you can get both in the same person. If the people working on software are great architects of solutions and are great coders, you don’t need many of them.

The whole point of writing this article is in its title: Don’t overhire developers. You don’t need many developers to get something done. Two developers who are dedicated and driven, can in total do the work of ten developers who have no passion for what they are doing.

Brooks’s law

Imagine this, two people are working in a team and the deadline is due in two weeks, there is a ten per cent chance that if the two people working put in all the effort necessary, then the project will be shipped. The pace however in the last week has been rather sluggish.

Seeing this, the management decides something that seems obvious at first. They decide to double the team size for the next month by hiring two developers on contract.

Sound familiar? It certainly does and is a reflection of a lot of companies and software teams around the world. What the management does not realize is that since two new developers are hired, they would require a lot of time to be trained in the existing codebase in a way that they can get up to pace with the current requirements and also not to break anything existing in the process.

Now the two initial developers are cursing the management for having them go through the painstaking process of onboarding the other two developers, which takes their mind off the actual development process and inevitably leads to the product not being shipped on time and being delayed by another two weeks, avoiding which was the whole purpose of hiring two new developers. This is Brooks’s law and is often looked over when over-hiring developers.

Final Words

It might seem that more developers = more output. But it is not necessarily the case more developers can hinder a project’s progress. There are also conflicts of interests and patterns of developments which take time to resolve, ultimately stopping developers from doing what is to be done the most: writing code and solving problems.

Hence, don’t overhire developers. Hire the best developers and only the number of developers that are truly needed for a project should be working on it.