Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

The Effect of Adding New People to Project Teams

10.21.2009
| 7153 views |
  • submit to reddit

I've read quite frequently about the challenges we will experience when adding new people onto teams, including Fred Brooks' 'The Mythical Man Month', but having seen quite a few new people join the project that I've been working on over the last few months I think there are actually some significant benefits they can provide.

I think the impact new people provide is particularly useful on a challenging project where they may be able to have a much more immediate impact.

From my observations there seem to be two main ways that new people can positively impact a team:

Driving for simplicity

I think that new people joining a team may well be the best placed to judge the quality of a code base. Since they have very little to no context of the decisions made they only have the code to tell them the story of the project so far.

As a result of this they are the best placed to tell whether or not the code has been written in an obvious way because they will probably have trouble understanding what's going on if that isn't the case.

Although following certain design approaches can ease the reading of code for everyone on a team I think that after we spend a while dealing with a level of complexity it becomes normal for us and we don't feel the pain as much.

Having someone new come in and point this out is invaluable as it helps us to drive towards a more maintainable and easier to work with solution.

Enthusiasm

Something else I noticed is that the level of enthusiasm that new people have is often much higher than people who may have been working on a project for an extended period of time and could be feeling a bit jaded.

They haven't fought the battles or experienced the pain that current team members may have done so they arrive with few preconceptions and a desire to improve the way that things are being done.

When combined with their desire to simplify the code, the impact these people have can be quite significant.

An added benefit is that enthusiasm is contagious so some of it is bound to rub off on other members of the team thereby leading to improved morale.

In Summary

I actually found it quite surprising to notice the impact that new people can have because I'd previously been more inclined to believe that people who had worked on a project for longer would provide much more value.

From what I've seen new members to a team can provide a lot of value very quickly so it's certainly an approach worth keeping in mind.

From http://www.markhneedham.com/blog

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Andrew Arrigoni replied on Wed, 2009/10/21 - 9:51am

Except for maybe enthusiasm rubbing off, neither of these really will make adding new people to a late project finish faster which is still a kneejerk reaction by a lot of management.

The best time to bring new people on is either at the beginning or in the middle but not really the end. At the end of a project of certain scope, trying to rework large swaths of code usually will end in a death march. Better, IMO, to finish out with more complex code and ship the thing then make refactoring a priority during maintenance.

After so long, you just need to finish all the code. :)

Rafael Alvarez replied on Wed, 2009/10/21 - 10:17am

The problem is not with adding new people to a project. The problem, as described in the MMM book is adding new people to a project that is already late.

It is ok to add new people as the project is in progress (actually, most projects could start with one or two people and grow as needed) . But if your project is already late and near the deadline, adding more people will just drag down the productivity of the (most likely burned out) team.

Torbjörn Gannholm replied on Sat, 2009/10/24 - 3:15pm

Good observations. I think the bigger problem lies in getting the old team members to accept the newbies ideas, which often kills the good force.

Bernie Eng replied on Sun, 2009/10/25 - 10:05pm

While the author described the good aspects of having new people on the team, they are achievable via code reviews as well (fresh ideas, judge code quality and striving for simplicity). And I agree that these are all Good Things.

However, the actual problem lies with the fact that with the new members, it is expected that project timeline can be shortened and/or new features implemented without shifting the deadline. A typical example of this mistake would be to assume if feature A take 10 man-days with a guy from the existing team, adding 2 new guys would mean that both of them would take 5 man-days each to implement.

It is usually because of this assumption that the folks in the existing team would cringe. No ramp-up time for studying the existing code, understanding design decisions and getting used to the development style. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.