Will giving new recruits a separate subproject from experienced developers help the newbies ramp up more quickly?

Question

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?

=======

UPDATE

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.