Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 threshhold 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?

EDIT:

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.

share|improve this question
8  
you are not at the threshold of brooks' law, that was passed over a year ago. –  Ryathal Sep 13 '12 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 Sep 13 '12 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 Sep 13 '12 at 20:15
    
@DocBrown I added more details to the question. I hope it is clearer now. –  lortabac Sep 14 '12 at 8:47
add comment

10 Answers

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

share|improve this answer
    
That book is a bit pricey but I'm going to check it out. –  Green Sep 14 '12 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. –  DeveloperDon Sep 14 '12 at 16:43
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
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 Dec 9 '12 at 11:07
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
2  
+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 Sep 14 '12 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 Dec 8 '12 at 20:04
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
    
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 Sep 13 '12 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 Sep 14 '12 at 12:06
add comment

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.

share|improve this answer
    
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. –  hstoerr Sep 18 '12 at 16:30
add comment

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.

share|improve this answer
4  
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 Sep 13 '12 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. –  dasblinkenlight Sep 13 '12 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 Sep 14 '12 at 9:08
2  
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 Sep 14 '12 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. –  dasblinkenlight Sep 14 '12 at 10:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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