I've been kicking this idea around with a guy from work for about 6 months.

I'm currently working in a team that has an extremely good development environment. I was given a config spec for Clearcase, and was able to use this to immediately download the entire sourcecode base, the tools, and the utilities to build the software. All that was required was my standard development PC, and the support guys to "push out" a particular control package. It worked wonders. Download and compile with the application working first time in under 3 hours. Unfortunately, our project is missing automated build scripts, unit testing, code coverage and analysis and documentation tools.

Then - I looked at another project in the same company, with developers with skills similar to mine. The installation and development was what I would loosely call a mess. Not that they weren't using the right tools, or tools different to me, or anything like that, just that you couldn't get everything from source control, and get a "standard" development machine to run it. Instead, you had to download certain tools from the net, set up specific configuration directories, class paths, environment variables and testing configurations. This project however, has great unit testing and code coverage tools, excellent documentation via a wiki page, and automated build scripts on check-in. Meanwhile, they considered our testing environment and methods a mess.

The difference is that the skill sets of the developers are in different areas. The focus in our team has been more on packaging and consistency, whilst the focus in the other team has been more on making things more automated, and unit testing for developers. There is a massive opportunity here. Why not rotate one developer out of this team, into our team, and vice versa? In fact, we have other projects also, that could benefit from this. I'm sure that there are things that both the teams I've been involved in could learn a lot from other projects, and other projects could learn a lot from us.

This all lead to the idea of rotating developers between projects, on a regular basis. I initially thought that Paul and I might be a little insane to suggest this, but after reading Martin Fowlers take, I figured maybe I'm not barking mad after all.

The idea basically goes by implementing a queue. Each project generally has around 5 developers in it. First in, first out. At the end of each month, the developer who has been in the project the longest gets rotated into the next project. In larger projects, developers spend longer periods, supports the idea that larger projects generally have a larger code base.

Advantages

1. Seeding of ideas as new developers come in
2. Homogeneous use of tools and techniques as developers rotate between projects
3. Freshness. Developers who aren't enjoying a particular project know it is a finite sentence
4. Learning. Developers are continually learning about the business environment on a macro scale. They see the business as a whole, not as "their" project.
5. Mentoring. New ideas and techniques bought in need to be taught to existing developers.
6. Reduces key person risk by providing a broader range of developers familiar with the project.

Disadvantages

1. Losing a good developer to another team
2. Time lost in introducing a new developer
3. Cost of moving developer
4. Increased chance of middle managers perceiving developers as swappable resources. Thanks Steve - comment below

Of the disadvantages, I think the first one is the least relevant. The point is that in a large organisation, the project is below the entire company. It is a shortsighted view if we consider that a good developer can't provide benefit to the entire organisation by being rotated around. The corollary to this is that a "bad" developer will also be rotated out. But if an organisation has no bad developers, then does it matter if a good developer gets rotated out and another good developer gets rotated in? Another area however that DOES need to be addressed is that with the rotation out of any developer there is a corresponding loss in project specific business knowledge. For example, rotating from a share trading system into a CRM system will involve the loss of that particular developer. There are two ways I think that this can be addressed. The first is to ensure that there are enough quality business analysts that remain in the team and they contain the specific business knowledge. The second way is to ensure that adequate documentation is provided for in the code. Tools such as Doxygen and NDoc go a long way towards assisting this.

Time lost in introducing a new developer will certainly be an issue in the short term. New developers will not only need to learn a probable new environment and method of doing things, but also have to come to grips with the business understanding. The first issue will be mitigated as ideas and techniques start to become more homogeneous throughout the organisation, leaving the developer with the requirement of learning the project specific business rules. Again, the creation of adequate documentation in the code will go a long way towards mitigating this.

Finally, the last disadvantage really can't be helped. There is often a cost involved in moving a developer around. The cost of moving equipment, chairs and the plethora of books, marketing toys and junk that accumulates over a developers life in their current location, is a cost that can't be ignored. Whilst each developer might move only every 3-7 months (depending on team size), there will always be some movement. I'm not really sure how to mitigate this, given agile requirements of putting developers close to users, analysts and testers where possible. This is something that the individual organisation needs to weigh up.

I really think this is doable, and Martin Fowler suggests that Thoughtworks actively do it already. An interesting thought. There is one thing that I would like to mention though - and that is that I am NOT assuming that developers are interchangeable resources. I'm proposing we rotate them because they're NOT interchangeable. There are a LOT of benefits that can be gained from differences in development skills.