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.

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?

share|improve this question
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 –  BЈовић Jan 26 '12 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. –  David Wallace Jan 26 '12 at 7:39
1  
javana: We're gonna hire experienced developers –  Dmitry Negoda Jan 26 '12 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 Jan 26 '12 at 13:00
3  
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 Jan 26 '12 at 13:54
show 3 more comments

7 Answers

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.

share|improve this answer
1  
+1 to written set of requirements, they are outdated a bit... –  Dmitry Negoda Jan 26 '12 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 Jan 26 '12 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. –  Dmitry Negoda Jan 26 '12 at 16:16
    
Do you have an internal wiki, or is everything stored in word docs scattered over the LAN? –  Spencer Rathbun Jan 30 '12 at 14:54
add comment

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.

share|improve this answer
3  
+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 Jan 26 '12 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 Jan 27 '12 at 2:42
add comment

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.

share|improve this answer
    
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. –  Dmitry Negoda Jan 26 '12 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 Jan 26 '12 at 13:10
add comment

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.

share|improve this answer
    
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. –  Dmitry Negoda Jan 26 '12 at 16:04
add comment

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

share|improve this answer
    
Yes to all your questions extept the last one. –  Dmitry Negoda Jan 26 '12 at 16:10
add comment

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.

share|improve this answer
    
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. –  Dmitry Negoda Jan 26 '12 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. –  Dmitry Negoda Jan 26 '12 at 16:18
add comment

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.

share|improve this answer
    
We are talking about only 100K lines of code, it is not that complex, however thanks for the concern –  Dmitry Negoda Jan 27 '12 at 11:47
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.