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.
Minimizing Ramp-Up Time for a Software Project
Some of these items are management related, some of them are not. Here's the list in order of importance:
1) Have an automated test suite that you can run with a single command, and use continuous integration (CI).
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.
2) (Ping-pong) Paired Programming
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.
3) Maintain a wiki with "static" documentation, or environment documentation
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):
- How to use relevant software development tools for your particular team (BitBucket, Gitlab, TravisCI, Jenkins, Bamboo, git/svn/mercurial/version-control, etc)
- How to log in to the test/prod environment
- What the development workflow looks like (one-flow, gitflow, etc)
- How to create accounts a dev might need
4) Getting the environment in order before the new dev joins the project
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.