Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Over the years, I have heard many times that adding more developers to a team does not make things faster. My opinion is that it's a question of management. If you can allocate one complex screen of a mobile app per developer, and you have 8 such screens, it might be beneficial to have 8 developers (e.g 4 permanents and 4 contractors) on it if a deadline looms.
What are your thoughts / experiences on that ?
This is about task resource elasticity and the law of diminishing returns. Some tasks of outstanding resource elasticity, in that adding labor input produces additional output, including a reduction in duration. Others tasks do not. And this assumes that the environment, technology, tooling, and other work enablers are fixed. If those things are not fixed and can be moved, then so too the elasticity moves as well as the point at which output begins to diminish. All of these things on a project requires analysis before you conclude that adding labor input would have adverse consequences.
I've always heard (and experienced) it as "Adding more developers to a late project will make it later."
Every new developer requires ramp-up time to be familiarized with the project's architecture, domain, etc. This requires time not only of the new developer, but of a mentor as well. So, your initial velocity will be slowed down. Eventually, though, it (might) speed up compared to before.
It sounds like the idea you're concerned about is a rather over-simplified version of the point raised by Fred Brooks in the (rightly) famous essay The Mythical Man-Month. What Brooks pointed out is that you cannot just treat developer man-months as an infinitely elastic resource -- so doubling the number of developers does not halve delivery time. There are two main reasons for that:
(In addition the point raised by @Sarov about ramp-up time is relevant but I do not believe it is significant except on very short timescales - unless, as noted by @Erik, we are talking about inexperienced developers being added to a team.)
I believe that it is the second reason that is the main factor. Communications overhead and the difficulty of keeping everyone clear about what they are meant to be doing, how parts communicate with each other, who is responsible for what, repeating mistakes because lessons have not been learned -- all these things and more mean that teams tend to become less efficient as they get bigger.
Note however that neither Brooks nor I are saying that adding more developers will always make a delivery later: that is stretching the point too far. What we are saying is that the relationship is not linear. Doubling the number of developers will not halve the development time - it might reduce it by 30%, for example, but you can not assume that it will reduce by 50%.
I'm not a manager, but I've had a lot of experience both transitioning to new software teams myself, and watching others transition to teams that I've been a part of. There are a lot of factors that go into whether or not adding developers will speed up a project.
There will always be some ramp-up time for a new developer. It's important to minimize this time. If you don't actively work to minimize ramp-up time, I conjecture this is where we run into the case where adding a new developer will (permanently) slow down the project.
Some of these items are management related, some of them are not. Here's the list in order of importance:
This is by far the most important item on this list, and there are so many pros to doing it that I haven't even written about all of them here.
From a developers perspective, joining a project that already has a test suite and continuous integration rolling is very easy. The reason is, I can make a code change with impunity (if a dev isn't make code changes, then they aren't very useful). If I make a bad change, then the test suite will break when I run it. When a test suite breaks in a dev's local environment, that's actually a good thing. We just caught a bug early, fast, and no one was involved with the bug hunting except the new developer who tried to commit a breaking change.
Look at any Github project that has 1000+ contributors. Almost all of them have run-able test suites (I actually can't find one that doesn't and has 1000+ contributors), and are typically using some form of CI. If your corporate software has a test suite and is using CI, you can add developers and have them all working harmoniously and have them be productive. CI is the only sane way I know of where you can have 100s of developers contributing to the same baseline. If you don't have CI, you simply can't effectively scale past 2-5 developers (well, you can, but then each developer will just cost you more time than they save you).
Have you ever seen 20 million lines of code and you're not even sure how to run it or where the main entry point is? Then when you do finally figure out how to compile it, and make an executable, (which might have taken you weeks) it keeps seg faulting on very reasonable input? Been there, done that, and it's a huge waste of time. A test suite also avoids this particular problem. A simple test suite (even with only a handful of tests) can go a long way on a legacy project.
Some teams like to keep wiki's that state how to run their code and list some simple test cases. DO NOT DO THIS. Wiki's always rot, and sometimes lie. A running, live test suite will not rot if you run it often and fix failing tests. If you use CI, the test suite can't rot. If it was rotting, then the tests would be failing, and builds would get kicked back from your CI server.
Furthermore, lack of docstrings or documentation? Who cares. Documentation lies all the time: code never lies though. A test suite is much more valuable than ANY documentation you're ever going to find, hands down. A test suite is living, runnable, documentation. I'm not saying don't write comprehensive docstrings/documentation, but given the choice between a test suite and documentation, I'll take the test suite every time.
The catch here is that you have to have relatively skilled programmers, and they have to be willing to write tests when they submit a change. Writing high quality tests is not something that you can teach someone how to do overnight. It takes practice, patience, effort, trial/error, and time. Sometimes this means a culture change.
Ideally, you have a test suite and CI, since it's the best way to help devs spin up on your project. If you don't, start building one. I recommend reading Working Effectively With Legacy Code by Michael Feathers.
If you don't have a test suite, like it or not, you have legacy code, even if it was written yesterday. That is Michael Feathers' definition of legacy code, and it's the best definition you'll find on the subject. Read his book.
Given you already have CI/test suite:
New dev pairs with senior/experience dev. New dev writes a unit test for a task on your board (yes, write the test first). Senior dev writes code to implement said test. Now senior dev writes a unit test for the task. New dev implements production code to satisfy said test. Rinse and repeat until the task is done.
This allows both a new dev to get some guidance with the baseline, how to build/run the test suite, how to write solid tests, and also gets to know the senior dev on a more personal level and fosters that communication and boding.
Senior dev also gets a (small) glimpse into potential strengths/weakenesses of their new dev and can plan accordingly. For instance, if new dev Johnny is a very strong with filesystems and networking/socket coding, but weaker with linear algebra, maybe don't have Johnny implement the code that calculates the pairwise cosign similarity over a set of vectors (at least not without a partner). And, maybe let Johnny teach the team a thing or two about filesystems and networking by assigning him tasks where he can shine in those areas (i.e. pair him with people who are weak in networking/filesystems). Easiest organic knowledge transfer you'll come across. Ping pong paired programming can also help with ramping up on esoteric domain knowledge.
Given you are now building your CI/test suite:
See the above. The best way to start a test suite also happens to be using this strategy. It might be best if two senior devs start a test suite this way, however, instead of the new dev and a senior dev. It provides sanity checks between two parties where both parties are probably new to automated testing.
Wiki's are most useful when storing information that is relatively static (i.e. not code) and unlikely to change. Examples include (but are not limited to):
This one is simple and often overlooked. If you're hiring a new developer or developer(s), then please have the items ready that they'd need to he productive. When they show up, the first day, they should be able to log in, clone the baseline, and at least start looking at what tasks they'll be doing soon. If you don't have a laptop or machine ready for them, then they can't do that. If you didn't provision them an account or the right SQL grants, then they can't do that. Just put in some time for this simple prep.
It also just feels bad when your manager/team didn't take the time to get you set up. When you show up for your first day of work and you don't have your laptop and can't login, that really sucks.
HTH!
