Mark Needham

Thoughts on Software Development

The effect of adding new people to project teams

with 10 comments

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.


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.

Be Sociable, Share!

Written by Mark Needham

October 21st, 2009 at 6:06 pm

  • The impact you are referring to is only short lived as their enthusiasm will quickly be dragged down (or up) to the level of the rest of the team and any opinions on the quality of the code will only be relevant whilst they are not familiar with the context.

    These are valid observations but I thing your wording suggests you feel new people in general will immidiately add as much value as existing team members which I think is misleading. In the vast majority of cases it will only go to slow the team down.

  • It is important to recognize that Brooks was talking about adding people to a late project as a way to, presumably, get the code done faster since the remaining volume would be divided between more people. The communication overhead generated by adding people (presumably) not familiar with the system, and doing so late in the game, was a crucial part of the “adding people” issue Brooks described.

    Adding people much earlier and in smaller teams (and, perhaps, with some understanding of the domain) is not going to be anywhere as problematic as what Brooks was describing.

    It is also important to recognize that the adding of people was based on the supposition that a volume of code could be divided by a volume of people evenly. So, to get code done sooner, you’d just have to add more people. We know it does not work that way in reality, but reducing things to sheer numbers can get you to making this assumption.

    Tom DeMarco’s book “Slack” has a number of nice points to make about how to allocate people and avoid treating them (and their time) as some fungible resource.

  • @ Rob

    I’d contend that whether newcomers enthusiasm and ideas are levelled to that of the team is an indication of how accepting the existing team is to change.

    What is value in the context you refer to? New peoples alternate opinions are surely as valuable as others which isn’t bound to a persons length of time on a project, and may well prevent the team from repeating past mistakes rather than slowing them down.


  • Pingback: Random Links #68 | YASDW - yet another software developer weblog()

  • @Rob – I guess it depends how you judge ‘value’ that different people on a team provide.

    Someone who knows the code really well, knows how the system works and so on is useful to have on a team but I think new people provide a different set of qualities that complement these really well.

    I haven’t noticed that the new people added to the team I’m working on slowed us down. Actually they seemed to bring a new perspective on how to solve problems and had interesting suggestions on better ways to do things.

    I don’t know if this would always be the case on every team but in this case that’s what we’ve found.

    I appreciate maybe my wording wasn’t great in some areas.

    @Scott – thanks for pointing that out! I often forget the context in which he made that statement.

    In our context we weren’t adding people to make a project go faster, it was part of a team rotation process whereby new/current people overlap for a month or so before the old people roll off. I found this worked really well.

  • Your roll off/on overlap example seems like it could work well. Though Brook’s point about communication overhead to get new people up to speed probably still applied. It just wasn’t in the context of a late effort trying to “make up” time. And the time you invested was well worth it as you would actually lose time otherwise if you had no way to replace people rolling off.

  • I don’t know if there’s a way to do it but it would be quite interesting to see whether there are times in a project when it makes sense to leave the team alone (maybe in the week of a release?) and when it makes sense to make changes (perhaps after having the same team for x amount of months).

    Speaking to some colleagues I’ve heard that a similar approach has been used on other projects and having a new person join has added a new lease of life into those projects as well.

  • Pingback: Agile: Constraints at Mark Needham()

  • Pingback: Mark Needham: Agile: Constraints | Software Secret Weapons()

  • Pingback: XP 2011: Michael Feathers – Brutal Refactoring at Mark Needham()