We have 7 developers in a team and need to double our development pace in a short period of time (around one month). I know there is a common sense rule that "if you hire more developers, you only lose in productivity for the first few months". The project is an e-commerce web service and has around 270K lines of code.

My idea for now is to divide the project in two more or less independent sub-projects and let the new team work on the smaller of the two sub-projects, while the current team works on the main project. Namely, the new team will work on checkout functionality, which will eventually become an independent web service in order to decrease coupling. This way, the new team works on a projects with only 100K lines of code.

My question is: will this approach help newbie developers to adapt easily to the new project? What are other ways to extend the development team rapidly without waiting two months until newbies start producing more software then bugs?



This enterprise failed completely, but not for the reasons you guys mentioned. First of all, I was misinformed about the size and capability of the new team. I should have evaluated them myself. Second, hiring turned out to be a hard job at that site. At the site of the main office hiring was much more easy, but in the city of the second team there was apparently shortage of developers with the required qualification. As a result, instead of projected 1.5 months the job extended to about 4.5 months, and was cancelled in the middle of it by the top management.

Another mistake I made (and was warned about it by Alex D) is that I was trying to sell refactoring to the top management. You never sell refactoring, only features.

The startup turned out to be successful anyway. The refactoring that never happened turned into technical debt: the system became more monolithic and less maintainable, developer productivity gradually decreased. I am not in the team now, but I do hope they complete it in the nearest future. Otherwise, I wouldn't give a penny for the project's survival.

  • 2
    if you hire more developers, you only loose in productivity in the first months - I never heard if it, but I am sure it's more Commented Jan 26, 2012 at 7:29
  • 2
    What happens when you try to integrate the two parts back together? Is there a chance that the two pieces will each pass their own tests, but a big integration test across the whole lot will fail? I suspect that you're going to find that Brook's law is not so easily circumvented. Excellent creative thinking though; worth a +1. And I'd really like to know how this works out for you. Commented Jan 26, 2012 at 7:39
  • 1
    javana: We're gonna hire experienced developers Commented Jan 26, 2012 at 12:07
  • 2
    @DmitryNegoda If you can find them in enough time. Experienced developers are typically not out of work so even if you interview them and offer them a position tomorrow they will probably need to give their current employer a few weeks notice before they can even start. If I were you I would prepare a contingency plan just in case, like preparing to work nights and weekends for a while.
    – maple_shaft
    Commented Jan 26, 2012 at 13:00
  • 4
    no matter how amazing of a developer you get, they aren't going to understand 100k lines of code in less than ~1 month maybe 3 weeks
    – Ryathal
    Commented Jan 26, 2012 at 13:54

7 Answers 7


Altought, Im agree like the everyone else here, that:

"...adding more developers to a delayed project, makes the project, to delay more..."

I have the feeling, you are going to do it, anywhere, so...

Your idea may help, if, your existing project, is enough organizated, by modules, subsystems or subprojects.

What you may want to try, its to give them small pieces / modules / forms / classes of your project, to work with, instead of all the project.

If you use a database, you may want to make a copy of a working D.B. with data, and access them from the module or subsystem of code there going to work with.

Having new developers that know the programming language or programming enviroment, is not enough, software aplications can become very complex.

Do you have some documentation of the aplication like: U.M.L., E.R., Codd-Yourdon, whatever ?

Good Luck.

  • We are talking about only 100K lines of code, it is not that complex, however thanks for the concern Commented Jan 27, 2012 at 11:47
  • 1
    @Dmitry Negoda: complexity is not a function of LOC.
    – jmoreno
    Commented Jun 12, 2015 at 13:51
  • There is considerable research (e.g. by Boehm) which shows that programmer's productivity, on average, is a function of LOC. Commented Jun 21, 2015 at 10:51

My question is will this approach help newbie developers to adapt easily to the new project?

"Newbie" might mean new to you, or it might mean new to working as software developers at all. If you're going to hire a group of developers to work on an important project on a schedule, make sure that at least most of the new hires are experienced developers, and preferably ones who've written projects similar to what you're trying to build.

What are other ways to extend the development team rapidly without waiting two months until they start producing more software then bugs?

  • Buy or license an existing product instead of trying to build your own. Do you really need to reinvent the checkout wheel?

  • As I said above, hire people who have experience building the kind of system you want.

  • Even before you hire this new team, you should be thinking about what they'll need to know about your existing stuff. Make sure that you reserve enough time for training sessions to help bring them up to speed.

  • Have you created a written set of requirements? If not, do that now. If you expect to be designing the project instead of letting the new team do that, you should prepare a clear design document as well, but be open to changes in response to input from the new team members.

  • Do you have a well-defined development process? Bug database? Version control? Code review process? Style guide? Get those things in place.

  • Don't expect miracles. You want to hire a seven person team and have them working productively in a matter of weeks, but wanting it doesn't mean that you can have that. Depending on where you're located, it may take a lot longer than a month just to find seven suitable people. Trying to rush things now will only cause pain and expense later.

  • 1
    +1 to written set of requirements, they are outdated a bit... Commented Jan 26, 2012 at 8:07
  • 3
    And who's going to interview these new hires, update the written requirements and design docs, fill in the bug database, spend time on the training sessions...?? Is it the current developers? Because that means they won't be developing full-time. So development speed goes down. Oops.
    – MarkJ
    Commented Jan 26, 2012 at 13:59
  • The code is self-documenting, and we're gonna hire experienced develpers only. And yes, current developers will help the new ones, and their speed will go down a bit. I am just hoping that hiring developers in 100K loc project will be not that painful as hiring in the 270K loc project, and that was the question. Commented Jan 26, 2012 at 16:16
  • Do you have an internal wiki, or is everything stored in word docs scattered over the LAN? Commented Jan 30, 2012 at 14:54
  • 1
    100k, 50k or 10k will all represent the same thing - a ton of code that no one person will be transferring into their head. If there are several hundred lines of code, that is reasonable. Once you get over several thousand you have a complex system and wishes for speed are often not achieved. Commented Jun 12, 2015 at 10:50

IMHO putting all the new developers on the new project, separated from your existing team is bound to bring problems. Yes, this (may) let your old team keep working more or less at its current pace. However, the new guys won't have a clue about the overall architecture and the big picture, so they will take a lot of time getting up to speed... and even then they may be heading the wrong direction.

I suggest dividing your existing team into two and hiring new members into both teams. This way there are people in both teams who can mentor the newcomers and ensure that a common, coherent architectural vision is kept up.

Otherwise, I agree with Caleb regarding documenting clear requirements, defining the development process and tools, and reserving time for training... and also on that expecting a team of 7 to get hired and get up to speed within a month is irrealistic.

  • 4
    +1 - you definitely want to use your old developers to bring the new guys on board. Although it is inevitable that this will slow you down for a bit.
    – mikera
    Commented Jan 26, 2012 at 10:35
  • +1 as well. You want your seasoned developers to mentor the new people. Even if the new guys have a lot of experience, they aren't going to know exactly how your company does things.
    – Andy
    Commented Jan 27, 2012 at 2:42

Dmitry, doubling your development pace in a short time is an incredibly ambitious goal. Some good suggestions have been posted here; but, no matter what you try, be aware that it may not happen. if your pace of development does not double, what would the consequences be, from a business perspective? Are you trying to push to meet a deadline?

If you are trying to meet a deadline, could you do it more reliably by cutting features? I have found a great way to make "missed deadlines" acceptable to a customer is to do incremental releases; release a version which has a subset of the required features, and then as more features are ready, release them incrementally, up to the final release.

  • There are no deadlines yet. We are expecting a serious increase in the number of potential clients by creating partnerships. We just wanted our solution to be more competitive, so that the partners would choose us. Its not the deadlines we are after, its demonstratable ability to deliver new features. But thanks for the concern. Commented Jan 26, 2012 at 11:33
  • If that is the case, perhaps rather than aiming to double your development pace in one step, maybe you can try to "ramp up" over a period of time.
    – Alex D
    Commented Jan 26, 2012 at 13:10

So you are trying to be the team that doesn't fall victim to the Mythical Man Month. You will have several problems, somebody on the team will have to do the technical interviews, then you will have to wait a few weeks after they accept the position before they can start. It may be two months before the new developers are in front of their keyboards.

Every new employee has a negative productivity in the first few months. It is made worse because the current developers will need to mentor them, further decreasing the tems productivity.

The other part of the MMM was that as the team grows so does the communications problems. Meetings become larger, email chains become longer...

I would bring them on in smaller groups and know that for a long time the productivity will not be proportional to the increased size of the team. Also realize the the drain on cash flow during the first few months can be significant, due to on boarding costs, and equipment.

In your comment to Alex D you mentioned "Its not the deadlines we are after, its demonstratable ability to deliver new features." So switch to a development style that roles out the features in smaller chunks, and more often. Have the new members of the team test the new features, that will help them understand the code base.

  • I don't understand how testing new features will help understand the code base. We are hiring QA engineers too, so let the developers develop and testers test. Commented Jan 26, 2012 at 16:04

You would be better off hiring no one new and looking at your processes to see where you can make changes to make things go faster. The sooner bugs are found, the less time it takes to fix them, so how are you testing? Are you doing code reviews? Are you paying attention to the quality of the requirement? Do you have autiomated builds and deplotyment processes? Do you have automated tests? Are you having daily standup meetings (Amazing how much faster development can go when someone will ask you for your prgress every day!)? Are you using agile processes? Do you have some basic design flaws that should be addressed to make the rest of the development go faster (bad design can slow a development project down incredibly).

Please read the Mythical Man-month. You clearly are going to need to in order to be able to tell senior management why they are making the worng choices to speed up a project. .

  • Yes to all your questions extept the last one. Commented Jan 26, 2012 at 16:10

So you want to throw them off a cliff and see if they can fly? I think when you discover things on your own, they tend to stick with you in the long run as opposed to just having solutions given to you. However, that assumes you actually do discover better solutions. I don't see why you can't allow this team to have a qualified leader who will balance letting them make some mistakes on their own along with giving them guidance and instruction by learning from quality examples.

  • Mike Partridge has changed my question. I am not gonna throw anybody off the cliff. Of course new developers will work together with the experienced, just on a different subproject. Commented Jan 26, 2012 at 16:12
  • I am just hoping that hiring developers in 100K loc project will be not that painful as hiring in the 270K loc project, and that was the question. Commented Jan 26, 2012 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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