So here's the deal:
I'm working on this project that is pretty large, and extremely nuanced (it's a solution for automatically drafting glass in a building after the building has been architected, but before construction). I'm working on a team with just one other person. He is a designer who has been in the architecture industry for several years and has partnered with the business owner to create this software. So, I'm the one who understands how software works and he's the one who understands how the architecture works.
Anyways, I am the only developer and have therefore taken on a ton of responsibilities, including architecting the entire solution, designing a database, organizing the workflow into three data-entry applications and one end-user application, choosing which technologies to use, building the entire front-end of those applications, and so on.
There are some things I love about being a solo developer - the codebase is all mine; I know it inside and out; and so on.
But I often wish I had another developer to take on some of the tasks and to collaborate with, and I feel like adding another developer to the team could greatly increase our productivity if we do it right.
However, I keep running into the idea of Brooks' Law that states:
Adding human resources to a late software project makes it later.
My question is:
Does this law apply to small teams like mine?
Everything I read on the subject has to do with teams at least several times as large as mine, with project managers and senior developers and such, so it's hard to relate to those examples. Articles consistently refer to the fact that a newcomer to a project ALWAYS has less experience in the project and therefore can NEVER contribute as quickly or as well to a project as those already working on it. However, in my situation adding one person is equivalent to doubling the number of software developers on the project, so there is bound to be a point where the increased productivity of having two developers exceeds the initial cost of training the new developer.
What tips or experiences do you guys have that could give me insight into how to know when and how to add another developer to the project?
Thanks in advance!
Top comments (1)
The idea behind that "law" is that adding new developers to a project will both: 1) require time to get them up-to-speed on the project and the codebase, and 2) require time from existing members to help them get up-to-speed. It basically says that adding new developers near (or after) a deadline will not help reach that deadline any faster.
That being said, adding new resources to a project will absolutely improve velocity...in the long term. It is an investment, in more than just money. They need time to get up-to-speed, familiar with the terminology, the technology stack, the specific ways you've got everything set up. If your company is able to afford that much time right now (which could very easily be many weeks or months), then adding a resource is a good investment.
But you might start to receive some pushback from the business if, after a while, they aren't getting the new features they want. That's where you, having "boots on the ground" so-to-speak, need to be able to track the progress of the new developer and show the business that they are getting increasingly more productive, how much longer until they can expect to see significant improvements to overall developer velocity, and ultimately that they are getting their moneys-worth. It just takes time, sometimes a lot of it.
Business-people just want to see new features, and there's always a constant struggle between making "invisible improvements" that pay off in the long-term, and shipping new stuff that makes the higher-ups happy in the short-term.