I run a small company composed of only 2 developers. We are building a very big application for one of our clients. Development on this project has gone on for 1.5 years.

Now this client has secured an important sponsorship, and they are organizing events related to this project. So now we have a deadline in 2 months and we can't miss it.

We are thinking of adding a new developer to the team, and I am wondering what we can do to help his integration.

This is the situation:

  • We are approaching the threshold of Brooks's law -- the point when adding new developers will be counter-productive.
  • The application is relatively well-designed, but the implementation is chaotic in some points (especially older code).
  • There are unit tests only for more recent code. When this project started, we didn't regularly conduct tests.
  • Documentation and comments are incomplete.
  • The application is both large and complex.
  • The client has written down almost every detail about his project, in a very clear and "programmer-friendly" way.

Is it a good idea to add a person now? If so, what can we do in order to help the new developer integrate into the team?


The sponsor is organizing an internet-based sport event for next spring. It must start on a specific day of the year. We can't change it.

What we developers (I am one of the two) need to do is:

  • Completing the existing application (about 25% of the work to do).

  • Creating a new module, essential for the organization of this event (about 75% of the work to do). This new module can't be developed without understanding the main program's API.

I can't do an exact time estimation, but we are in a risky situation.

  • 11
    you are not at the threshold of brooks' law, that was passed over a year ago.
    – Ryathal
    Commented Sep 13, 2012 at 18:03
  • 3
    You did not write one word about what goal you have for that deadline. Add some features specific for that sponsor? Make a product presentation for the events? Create an installation package? Fix some of the most important issues? What problems do you have you cannot solve with your current team?
    – Doc Brown
    Commented Sep 13, 2012 at 19:42
  • How much time do the 2 developers believe they will need on their own? 3 month (calculation being 2 devs * 3 month equals 3 devs * 2 month)?
    – scarfridge
    Commented Sep 13, 2012 at 20:15
  • @DocBrown I added more details to the question. I hope it is clearer now.
    – lortabac
    Commented Sep 14, 2012 at 8:47
  • "Documentation and comments are incomplete" ... "The client has written down almost every detail about his project, in a very clear and "programmer-friendly" way". Get the new guy to translate the client’s writings into design documentation, then "There are unit tests only for more recent code. When this project started, we didn't regularly conduct tests" get him to write & run tests. He won't be getting in your way and will be contributing to the project
    – Mawg
    Commented Jun 9, 2015 at 10:04

10 Answers 10


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.

  • Adding Unittests for the old code and fixing bugs are some ideas what the new developer could do - of course with support and code reviews by the others. Maybe there is need for automated UI test? That's also something the new dev could do and learn much about the application. Commented Sep 18, 2012 at 16:30

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.

  • 6
    It depends how far behind they are. Consultant will cost more and take the knowledge with him when he leaves. Also finding anyone that would require near-zero start-up time is probably wishful thinking.
    – Nik
    Commented Sep 13, 2012 at 18:01
  • 1
    @Nik I agree, higher cost is definitely a tradeoff; so is the knowledge draining away from the project. Getting a near-zero-start-up person is hard, especially on a short notice, but I've seen it done on several time-critical projects. The costs of hiring them were quite high, though. Commented Sep 13, 2012 at 18:09
  • I will do some research, but an experienced consultant might be difficult to find in my area. Do you think it would be possible to work with someone from another city? Or would distance furtherly slow down the process?
    – lortabac
    Commented Sep 14, 2012 at 9:08
  • 4
    I guess Brook's law applies to an experienced consultant as well, so I don't think this will be a real solution for the problem.
    – Doc Brown
    Commented Sep 14, 2012 at 9:08
  • @lortabac Adding someone to work with you remotely will very likely slow things down. How flexible are the sponsors on trimming the requirements for the additional module? You may want to ask them to sort the new features in the order of importance, and decide what is the absolute minimum of the requirements that you must implement in order for the event to make sense. If you cannot get a "firefighter" locally, reducing the scope may be a good contingency plan for you. Commented Sep 14, 2012 at 10:28

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).

  • 4
    +1. Despite all the well-intended, higher voted other suggestions, I think this is most probably the only thing that will really work in such a situation.
    – Doc Brown
    Commented Sep 14, 2012 at 9:14
  • Agree wholeheartedly. If you have two months left, and you are merely thinking of hiring someone now, you won't get much out of a new hire. Unless you are fantastically lucky or have someone competent already in mind, you are either going to waste two months looking (and detracting from your own productivity) or hiring someone that will just make things worse. Don't rush your hiring.
    – jmk
    Commented Dec 8, 2012 at 20:04

Don't do it.


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).

  • That book is a bit pricey but I'm going to check it out.
    – Green
    Commented Sep 14, 2012 at 13:19
  • You may be able to find excerpts from the books I mentioned online, perhaps through Google books. I borrowed both the Brooks and Coplien books through my local university library. Commented Sep 14, 2012 at 16:43

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.
  • perhaps determine the areas that need work and have the new person start by writing tests for existing code, to aid in their understanding of the system before they dive into changing/adding to it.
    – StevenV
    Commented Sep 13, 2012 at 18:53
  • @StevenV that is an excellent, excellent idea. Writing tests for components you don't know will make you familiar with them very very fast. And the system is more testable when you're done. :)
    – Green
    Commented Sep 14, 2012 at 12:06

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 ;)

  • 1
    Few days after posting this question I left the company. As some comments on Ars Technica correctly pointed out, there were deeper problems which I haven't mentioned in the question. I just wanted to get an opinion on this specific issue.
    – lortabac
    Commented Dec 9, 2012 at 11:07

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.