Best thing to do is not to throw the new developer into the fire, but instead carve out some functionality and/or bug fixes that the developer should have no trouble jumping in to. Find an area that needs work that doesn’t require a person to know the entire architecture, requirements and code-base all at once. Maybe have him or her work on documentation to learn the system faster.

Rather than adding a new developer to the team, consider adding an experienced consultant for the two-to-three months period to handle the temporary increase in your company’s workload. The idea is to get someone who can handle near-zero start-up time, but at the same time may not necessarily be the best addition to your team.

Even if you think that the increase in workload is not temporary, now is probably not the best time to grow your team organically: adding a third developer is a stressful thing for a team even without a pressure from the project deadline; tight deadline only makes the transition worse.

The tradeoff is that in exchange for a temporary help you will get code written by an outsider. To mitigate this risk, make sure that both of you do all code reviews with him. Make sure that you review and understand all of his unit tests, too.

Is it a good idea to add a person now?

No.
If at all possible, try to have the client agree on reducing scope instead.

Adding a person this late will add significant risk, and the deadline can’t be pushed (as far as I’ve understood).

Don’t do it.

Yet.

Traditional View

In your question, you refer to Brooks’s law from Mythical Man-Month.

Adding manpower to a late software project makes it later.

To ignore Brook’s law carries a price. Don’t multitask. Focus on delivery of your Minimum Viable Product (MVP). Then focus your energy on recruiting, resourcing, training, and managing a new team member.

Two months is so short. Plan recruiting with a burn down list and you will see how time consuming it can be.

Larry Page and Sergei Brin spent two years choosing the initial team for Google. Your pick for employee number three should also be a careful one.

Agile, New Millenium View

Competition drives dynamic teaming more now than in the era when Mythical Man-Month was written (mid 1960s). Long careers at one company are gone. Now we migrate frequently between projects and companies. Rapid team building creates success. Slow ramp-up is a severe limiting factor. Great examples come from open source projects, startups, and the increased use of team projects in computer science courses.

Potentially, Agile teams factor constraints into their schedules. They are not late because they are optimized to the available resources. Integrating new staff is one more constraint, and considered as a trade-off between short-term and long-term goals. The Agile team continually integrates code, so why not people too?

Agile team technical and social integration for new staff can use:

• daily scrums
• pair programming
• refactoring
• adding missing unit tests
• fattening up lean documentation
• code reviews

The Sacrificial Lamb

In “Organizational Patterns of Agile Software Development” James Coplien discusses group dynamics and costs of adding new team members. His pattern “Sacrificial Lamb” assigns all mentoring and training to one person, guarding the rest of the team from interruption.

It’s a strategy that you may want to consider implementing.

Another strategy is to assign new hire mentor(s) who covers questions from new hires for particular hours each day. If you can spare only one guy, perhaps he works without interruption in the mornings or afternoon and answers questions in the afternoons or mornings respectively. The group I am in had ten interns last summer, so a lot of people were interrupted a lot.

Presently mentoring is done by one person, primarily during and immediately after our morning scrum (8:30 am until around 9:15 am, combined), and in the afternoon between 12 and 3:30 (he works 7 am – 3:30 pm).

I’m heartened that you mentioned Brook’s Law. Nicely done. The primary problem with adding another developer is the overhead in getting them up to speed and the overhead of synchronizing state with them about where you are in the project. Therefore, if you do decide to get a third developer, I would try this:

• Give the new guy an area where the up-to-speed costs are low and he can get going as quickly as possible. This will depend a lot on who you hire and what skills they have.
• Make sure this area is loosely coupled with other areas of the application so that the synchronization overhead is less. Sending him in to do intense DB work and reorganizing tables may be too much.
• Do what you can to keep morale up. As others have noted, adding a new team member can be stressful so perhaps an investment in fizzy beverages might help.

If you strictly follow Brook’s Law, you will likely never grow your team.

The trick is to bring on the new person without getting hit with too much slowdown on your current team. Eventually the new person will be up to speed, and you can get over the hump.

In your case? I would recommend have the new person write all those missing unit tests.

1. Those are sorely needed as a safeguard against regression errors,
   which will burn you faster than any Brooks slowdown.
2. New person will learn the guts of your system. It’s a bit of a
   trial by fire–but their output is not going into production code,
   so little risk there.
3. Place a hard limit on how much of the other team members time they
   can take. E.g., have them queue up questions, and only allow 30
   minutes a day interacting with other team members until the deadline
   is met.

Also, let’s face it: you will have to manage scope, and client expectations regardless of whether you bring on a new person or not. The payoff comes next cycle.

Ed Yourdon had a great comment about Brook’s Law. He said: of course, adding people will make you go slower–but when a project is at risk is the only time management will bring on new people. So: take them, minimize the impact to the current release, and get rid of poor performers as soon as you can. This way, over time, you can build a strong team.

If you have work on other projects that you can give him that will free up time for the 2 current developers to concentrate on the big deadline deliverables that could help.

You say you need to complete 25% of the original work, plus new work. ANd you need to do this in two months – when it took you 18 months to do 75% of the work. To be very blunt, this indicates to me that your estimation abilities are about average for a code-focused programmer – that is, you think things will take you about half to a third as long as they really do.

Heroics might allow you to deliver the product you’ve contracted for, but it won’t be doing you or your customer any favors. It will be shoddy and bug-ridden under these conditions, and you’ll be running on fumes.

Keep in mind that time you spend hiring will also have a major impact on your availability – this isn’t something you can just do in a weekend, it does take time to find talented employees that fit well. Expect to spend at least a couple of weeks searching, interviewing, etc. Expect that you and your existing employee will lose about 10 hours a week of productive time while you search.

My recommendation:

Sit down with your customer, explain that you’re in over your head, and work with him to reduce scope to bare minimum.

Edit Just saw the date here. So how did it end up? (Thanks Ars Technica for posting a three-month-old question 😉

There are a couple of different ways I’d consider investigating:

1. Hold off on hiring the new developer until after the deadline passes so that it would be easier to focus on passing domain knowledge to the new guy. This would be my preference as it could be slightly challenging in a few ways.

2. Bring in the new developer to work on documentation, unit tests and other stuff that isn’t changing any of the existing code. This would be what I’d suggest if you do bring on the new guy to try to minimize impact on the current work load.

The date has already gone by, but for anyone reading this later.

The key thing to consider is that the client in this situation has much more to lose than you do. They have already spent a lot of money, and they have a key event coming up that might make or break their business. You already have their money, and losing a single client should not break your business. If it does, then you have other serious business issues beyond terrible project management.

Your best bet is to negotiate an essential subset of functionality and then work overtime to get it done. If you can’t make a smaller subset happen or aren’t willing to work overtime in that situation, you probably shouldn’t be in business. This may mean putting other clients on hold, however I’m guessing your other clients haven’t paid for 3 man years worth of time, so put your resources where the money is.

If they aren’t willing to negotiate scope down, then you are set to fail.

There is no chance of delivering this project completely in the timeframe. If you think you have 25% left on a project that has taken 18 months to deliver so far, then you have at least 6 months left (of ~2 developers). Adding another person will not change this significantly.

As has been pointed out, recruiting takes time. My experience is that is takes a month at the bare minimum. Then add training and your time has run out.

I hope this worked out for you.