I would love to be the one that gets rotated and even though it doesn't happen a lot during projects my employer takes advantage of that personality trait in other ways. I don't think there is any one right or wrong answer. People have different needs, skills, annoyances. What's agonizing drudgery for one person is satisfying or at least acceptable for another. It's a manager's job to put everything together like the pieces of a puzzle.

One way to get started with this is to have members of each team be involved in the code reviews of the other team. That way you get the cross-pollination, and if/when you decide to move team members around the ramp-up time will be much less.

This obviously requires a commitment from both teams to be available for reviews, and to factor in some reduction in immediate productivity.

This makes almost as much sense as starting a project in C++11 and switching to C++98 half way through and using raw pointers again. Your new system obviously has new semantics and to switch programmers to the old now defunct way of doing things, or to have the old team spend time ramping up to the new way of doing things is just not productive. Sure it may sound nice from a point of view of keeping the legacy team happy, but I guarantee you the new team isn't going to like it one bit when you start asking them to do things the wrong/old way again.

Where I work we have 6 programmers (plus a few designers and sysadmins who do a bit of light coding) and manage over a thousand websites.

Most of the sites are pretty simple but a few are massive projects developed over several years.

We obviously rotate a lot, and it works OK. But it's not easy. We are very strict about coding conventions and general structure. If I'm assigned a job telling me to improve X feature I can guess the file name and method without even having seen the code yet.

Without that, I don't think it would work well. We have a few sites that aren't following our standard conventions and things often go south when someone unfamiliar works on it. They introduce a lot of bugs, so we try to have one or two people working on those projects exclusively.

The trade-offs that come from rotating developers don't seem worth it to me. Spreading knowledge around and giving people different experiences is good, but the cost is that you don't have as much opportunity for people to develop true expertise or connection to the project. And while shelves full of books on software development often like to pretend otherwise, the fact is that having knowledgeable "champions" on projects is by far the most effective way to make the project succeed in my experience. 3 people with some experience with a project are not going to be as good at coming up with improvements and fixing bugs as one person with deep knowledge of the project because expertise is not really multiplicative that way.

The other problem is more a personnel management issue, often described using terms like "bus factor". The idea is that it's bad for any project in an organization to rely so heavily on one person in case they get hit by a bus or get a better offer somewhere else. But while that may be a problem for an organization, intentionally trying to devalue an employee's contribution doesn't seem like a very good way to create much employee loyalty. It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

I've worked on teams that swapped between full-time development and full-time testing roles. It is amazing how much better our code became after 6 months as a tester. Our bugs dropped 75%.

Also worked on teams that rotated across different projects. Overall, I'm not so certain how much this really helped, but * Everyone should have to be a maintenance programmer for 5 yrs before being allowed to spew their own crap code.* we all suck at something, just in different ways* my suck-i-tude gets corrected by the-next-guy* I fix the last-guy's suckiness* Fresh ideas for problems* Cross-training means ** no 1-trick ponies in the company** no single point of failure if someone decides to leave** more relaxing vacations - since you have a highly knowledgeable backup/replacement* Sometimes bad projects are just - er - bad. Knowing it is just 3 months isn't enough to make anyone leave a company.

Cross-training is almost always good, if not taken to extremes and time is left to be productive.

I've worked on teams that swapped between full-time development and full-time testing roles. It is amazing how much better our code became after 6 months as a tester. Our bugs dropped 75%.

Also worked on teams that rotated across different projects. Overall, I'm not so certain how much this really helped, but * Everyone should have to be a maintenance programmer for 5 yrs before being allowed to spew their own crap code.* we all suck at something, just in different ways* my suck-i-tude gets corrected by the-next-guy* I fix the last-guy's suckiness* Fresh ideas for problems* Cross-training means ** no 1-trick ponies in the company** no single point of failure if someone decides to leave** more relaxing vacations - since you have a highly knowledgeable backup/replacement* Sometimes bad projects are just - er - bad. Knowing it is just 3 months isn't enough to make anyone leave a company.

Cross-training is almost always good, if not taken to extremes and time is left to be productive.

"more relaxing vacations - since you have a highly knowledgeable backup/replacement" - Best part

"* Everyone should have to be a maintenance programmer for 5 yrs before being allowed to spew their own crap code." - I have the interesting role of consulting, designing, architecting, and programming custom applications and systems for both internal and customer use. Seeing other aspects of the life of a program/system is very useful.

The other problem is more a personnel management issue, often described using terms like "bus factor". The idea is that it's bad for any project in an organization to rely so heavily on one person in case they get hit by a bus or get a better offer somewhere else. But while that may be a problem for an organization, intentionally trying to devalue an employee's contribution doesn't seem like a very good way to create much employee loyalty. It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

Do you know what it's like to be spending a day with your family, when the boss calls you and says there is a bug thst has to be fixed RIGHT NOW or else the company is going to loose $300,000? I've had calls like that.

Sure, they can't force you to cut all your plans and drive to the office immediately to spend ~15 hours fixing the bug with no breaks. But they can, and will, transfer you to a position where you are never allowed to work on anything important/interesting again.

It is far better for everyone, including the employee, if multiple people are familiar with the codebase. If a second person is available then you won't even hear about the bug until you get back from your break.

One problem I have with Aaronaught's statement about rotating teams is that when you do that you end up with an entire team that knows nothing about the project they just got rotated onto, so you can't go to other people on the team with questions. And the other team's in the same boat, so they aren't going to be able to take time away from learning the project they're assigned to to spend time explaining the old project to you.

As far as Peopleware's position on team dynamics, as part of a development team I have to vehemently disagree. We are going to have team members moving on and off the team, simply because of normal turnover and business needs requiring reassignment of people. It's part of our job as software engineers to be able to deal with this. If we can't, we're in the wrong line of work. Sure it may be easier if they're there, but they aren't and it won't kill us to have to figure things out for ourselves. All that happens is that we end up learning more of the system than we did before.

Best bet is to have enough people that you can rotate a couple between projects and still have at least one person on the team who knows about any given part of the project. The easiest way to do that is to rotate people within a project, having the backup for part A become the primary developer for it while the primary developer becomes the backup for a part they aren't familiar with. Then you end up with everyone on the team being familiar with everything in the project and you've got a lot more flexibility in assigning work. The only exception would be areas that take a large amount of specialized technical expertise to work on, and when I'm involved in those I make it a goal to make those areas so that they don't need to be worked on very often. That and I make copious notes in the code about what I'm doing and why, so that the next person to read the code can see what I was thinking. Even if it's me, because after 5 years away from the code I'm likely to need to be reminded why I made that particular decision that looks silly but really isn't.

I'm not sure on this. Cross training is certainly important, and it is critical that no one on the team ever become completely irreplaceable, however you also have to run a business and you do not want to upset a cohesive and productive work unit. I'm not sure what the best solution is, but it's most likely something less dramatic.

It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

Some places really rub it in too.

And you know what, once you get to this state it's a trivial matter to simply consider all developers as interchangeable cogs and hire the cheapest ones you can, from India. "All programmers are the same and can be rotated without problem", so why not rotate the outsourced team onto all projects. That's how management will see it.

So we need to say that development is more difficult than ideas like this presume, and that built up knowledge, skill and expertise in the business system that has been developed is vitally important. That idea means that you are more valuable to the company, and not so easily treated like that cog.

Depends on the teams and developers and where their skills and passions lie.

Me, I prefer working from web service boundary down to system level sort of work. Hate everything UI, user interaction and the other human level stuff. Other devs I know prefer the "human" space and are great in that area.

If you have a team big enough that you can keep people in their happy spaces and rotate the jack of all trades that is great. Push people into areas that is not their interest and you will lose productivity and risk losing them to a company that will give them the work that does interest them.

From experience there are two types of devs. Those that learned to code because they saw the potential of a good wage packet and the others that code because it is who they are. The later are the people you want BUT they are also the the people further from the social norms and in general quirky.

Learn how you dev team is composed, where each person strengths and weaknesses are and make the best of that. Your team will thank you for it and you will get the most from them.

This is the kind of question you can imo only answer with a distinct maybe, given how it is asked.

I think everybody with a bit of experience knows the two opposite ends of the line.

There's the team that has kept hogging their thing for the better half of the last decade or more. You ask a question and through ever syllable you get as a response you can feel how this is all arcane knowledge no mere mortal should hear. Bu just listening to their dismissive "we always did it that way", you are already signing the pact that's intended to keep you doing just this project for the rest of your life. With people who are behind by two OS versions. Everybody who wanted something remotely interesting has jumped ship years ago.

The other end is when you get assigned a ticket for a problem concerning a system you probably never heard of. When you ask questions, you get told that you learned to program and know where the source lies. And as you have learned that, you're now supposed to do it. Does a chimney sweep whine when you give him a new brush or he has to visit a newly built house? No.And so people are sent to fiddle with things they have no idea of, neither doing any good nor actually learning anything.

Pretty much everybody I ever talked about this agreed that you need some movement and changes of pace and duty over time to avoid case I, while it also shouldn't be enough to border into case II.But where's the golden ratio?

And this is where I think the question is too vague to actually answer it in any direction. Having people floating around slowly between projects can be a good idea, if the differences between those projects are small enough and the intervals are long enough. And something that's often forgotten is that there's also a personal aspect, concerning the developer. Some people want to spend longer times with a project, because they are good at building deep knowledge and have fun in exploring any ins and outs of a codebase. Others seem to be bothered by that and get bored, but don't mind changing projects and having to familiarize themselves with a new codebase. There's no judgment implied.

Another thing is how close the projects are actually related. There's a lot of bandwidth and aspects.

Then there's the social aspects of teams and that alone is complicated enough. Between ripping apart and damaging a good team and making an already good team even better, exchanging parts of it can lead to anything. And again a lot there depends on the people you have. Some get excited and enjoy changing peers, as this inspires and motivates them. Others get mainly bothered by that and disturbed in their routine and concentration.

If someone does have a recipe for this that indeed works in general and is more specific than "don't do anything too extreme", I'm eager to hear it. I'd be surprised if it existed, though.

I usually dint like these SO cross posts. But I think this is a pretty good one. Mostly because I'm not at all convinced that there is a correct answer. I've read a lot of pros and cons here and both sides have good arguments to make.

As a lead developer turned CTO I look at this from the point of view of both the employer and employee. In both circumstances there are compelling arguments to be made for rotation and non rotation.

At the end of the day, I think variety and change edge out the competing options. There is value in developing very specialized mastery of one thing. But in my career I've usually found that doing something else has made me better at the original. Concrete example: learning ruby made me a better c# developer.

When learning to play the guitar. The more i focus on one song exclusively the longer it takes to learn it. Moving on to other songs and then comming back pushes that original song forward much faster than anything else.

You need to keep the employee fresh but allow them to also develop mastery. The employee should be given the opportunity to really own something they enjoy, but not be given the opportunity to get stagnant or complacent.

The business owners needs people with deep expert knowledge in systems, but it's a mistake to become to dependent on one specific person or team.

Ultimately I think the real answer is to find a happy middle ground, and it probably isn't the same middle ground for all companies, teams, and individuals.

I would consider, instead of always rotating members of teams out, having members of a roving team that move around the other teams and make cross-pollinating contributions or at least give various teams perspective on how other teams work. My idea is that moving people off one project onto another is almost definitely going to hurt that developers productivity - so that is a loss of dollars, basically. Spend those dollars instead on hiring someone whose job is to stitch things together, then, perhaps, you won't lose money and you will still keep some of the benefits of moving people around projects while shedding some of the obvious minuses.

Personally I find that the biggest challenge for productivity is boredom; there's nothing worse than working on the same project all day, every day, as even the most interesting one will eventually reach a point where you get some drudgery such as boiler-plate coding, testing and so-on. Obviously this stuff needs to be done, but there's nothing worse than reaching a test-phase and finding that that's all you're doing every day.

Working on other projects isn't necessarily the solution, though it's a possible one, though I don't recommend working on more than two projects at a time, but they should be as distinct as possible (to avoid creating confusion). It is however possible to do this with a single project if it's broken up into enough distinct pieces, this way you can assign two pieces to each developer, who can then alternate which one they're working on in a way that suits them. Even better, you can assign each developer a piece of code to develop, and assign that code to someone else to do black-box testing, such that each developer is working on one piece of code and testing someone else's, so your testing gets done but no-one is working with just one thing and one thing only. It can work well if your tester also does the test writing, as all a test writer should really know is the interface/API involved anyway.

Personally I work on one main project most of my time during a week and a smaller project for the rest. I also try to do testing in the mornings as I just find it so much more boring to do later on, plus stepping away for the night can help with coming back at it fresh. So for example, I might work on project A on Mondays, Wednesdays and Fridays, and on project B for Tuesdays and Thursdays. I'll then test project A on Tuesdays and Thursdays, and project B on Wednesdays and Fridays, leaving Mondays as my coming out of my start-of-the-week morning stupor time.

It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

Some places really rub it in too.

And you know what, once you get to this state it's a trivial matter to simply consider all developers as interchangeable cogs and hire the cheapest ones you can, from India. "All programmers are the same and can be rotated without problem", so why not rotate the outsourced team onto all projects. That's how management will see it.

So we need to say that development is more difficult than ideas like this presume, and that built up knowledge, skill and expertise in the business system that has been developed is vitally important. That idea means that you are more valuable to the company, and not so easily treated like that cog.

In my job, proper cross training takes about 3 years. I'm not sure I'd say that we're easy "replaceable". We are only recently trying to cross-train to make each other more replaceable with each other, but there is no way we could be easily replaced with anyone outside of our area.

My boss says that current estimates are that it takes about 6 months before a new programmer breaks even with value. It takes about a year to recoup the initial cost of hiring a new programmer.

But our department is in an interesting position. We need to work with the DB admins, Network Admins, Hosting Admins, Senior Engineers, VPs, and with the customers. Lots of coordination to get custom work done in a timely manner. We seem to have a target on our back now that we've gotten the reputation of getting work done quickly. So busy now.

We would have had a turn over of 0 if we didn't lose a programmer to moving back near family to start their own family. They've already got two kids... holy crap, time flies.

My point is that not all cross-training means you're replaceable, just interchangeable with your peers.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

What's agonizing drudgery for one person is satisfying or at least acceptable for another.

This is a strong argument against rotating people around.

No, it's a weak argument, or no argument at all. What if I've got a person who views maintainance of older code as agonizing drudgery assigned to that task and never rotate her off? She's gonna quit, and then I'm going to have to hire a replacement. But if I rotate her into a new code development role she loves, she'll perform great and I'll see what she can do. Maybe I'll decide to put her there more because she's a big benefit to the team in that role.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

Unrealistic. I have to develop on the projects that are contracted and funded. I'm not going to let primadonnas dictate what succeeds or fails for lack of attention.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

Unrealistic. I have to develop on the projects that are contracted and funded. I'm not going to let primadonnas dictate what succeeds or fails for lack of attention.

Micromanagement does not work. Nor does letting your sales staff decide what is doable. Your company turns out barely adequate software.

Generally, it seems that rotating developers around between major aspects of a single project is not the most efficient way to go. But in the case listed here, it appears more a question of two projects. The first legacy project and also it's replacement "new" system. In that case, it makes quite a bit of sense to get the team proficient with both code-bases (particularly getting the legacy folks up to speed with the new approaches),.

The idea of swapping entire teams doesn't make much sense to me. My strong feeling is that handing a half-dozen programmers a pile of code they've never seen before - also having participated in *none* of the planning/development/management meetings - and saying "OK people, here's the spec sheet, go to it." would not be likely to accomplish great results.

The least disruptive way to accomplish the apparent goal is to move a small number of team members and handle it essentially like bringing on a new-hire to the teams. Small personnel changes *should* be somewhat routine already just based on life. The developers already being familiar with the company (and likely coworkers) simply makes it less difficult than with a new outsider. It sounds like management is pretty much on point here.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

Unrealistic. I have to develop on the projects that are contracted and funded. I'm not going to let primadonnas dictate what succeeds or fails for lack of attention.

Micromanagement does not work. Nor does letting your sales staff decide what is doable. Your company turns out barely adequate software.

I hope you put more logic into your coding than you did into this (assuming you code). In the business model apparently being discussed here, sales staff negotiates what the client is willing to pay and what they expect for their money. Ultimately the *client* decides what *must* be done (assuming you intend to honor your side of the contract). Management is responsible for organizing the resources to ensure (a) the sales folks don't screw up and (b) that the development team gets the job done while returning a bit of profit to the organization.

It's not really possible for someone sitting in the developer's seat to have all required information to make strategically sound choices on a vast array of issues - if the point is to have a successful company.

Your scenario envisions taking a hands-off approach to the point of being non-management. To-whit, the manager just says "fuckit, you guys decide what you want to do ... and we'll just watch and see what happens." To a *degree* that kind of occurs anyway I guess; folks tend to get good at particular niches ... and teams tend to figure that out and dump that kind of work on them. But I don't think the idea of just letting people pick their tasks would work at all ... it would be chaotic, potentially lead to negative confrontations and could not in any way guarantee that all required jobs would be covered.

The person you insulted probably works somewhere turning out software that accomplishes exactly what the client asked for it to accomplish, produced in such a way that the developers were likely paid well and receive production bonuses upon efficient delivery. If you use other esoteric metrics to measure the success of a project ... well, I guess that's why you probably aren't a manager.

I think rotation is generally a bad idea and disruptive to the deliverables of the project.

On any project that's longer than a couple of months, there are probably non-trivial business processes that a developer has to understand to successfully implement solutions which are going to work for the customer. In theory, business analysts and designers would capture these things in their mock-ups and user stories, but I have yet to find coworkers in these positions who actually provide requirements at the level of detail required for a completed product. A developer who has spent six months attending planning meetings is going to have a depth of knowledge of the project that can't be transferred to another.

Then on the technical level, there's understanding the basic architecture of the application and custom wrappers/utilities that should be consumed. Of course developers could write documentation explaining these things, but usually there isn't enough time to maintain it and it's costly for the new developers to read it (especially if it's stale). Experienced developers get slowed down while they try to show the new guy the ropes. Even with good developers, I feel like every time we rotate in new people -- usually when they're in a lull for a month or two between other projects -- we end up getting code that reinvents the wheel. This unique code not only took longer to write, it's also more costly to maintain and often more laborious for the QA cycle as well. Then by the time they could start contributing to my project in a useful way, the project they're intended for finally gets off the ground and I lose them.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

Unrealistic. I have to develop on the projects that are contracted and funded. I'm not going to let primadonnas dictate what succeeds or fails for lack of attention.

Micromanagement does not work. Nor does letting your sales staff decide what is doable. Your company turns out barely adequate software.

I hope you put more logic into your coding than you did into this (assuming you code). In the business model apparently being discussed here, sales staff negotiates what the client is willing to pay and what they expect for their money. Ultimately the *client* decides what *must* be done (assuming you intend to honor your side of the contract). Management is responsible for organizing the resources to ensure (a) the sales folks don't screw up and (b) that the development team gets the job done while returning a bit of profit to the organization.

It's not really possible for someone sitting in the developer's seat to have all required information to make strategically sound choices on a vast array of issues - if the point is to have a successful company.

Your scenario envisions taking a hands-off approach to the point of being non-management. To-whit, the manager just says "fuckit, you guys decide what you want to do ... and we'll just watch and see what happens." To a *degree* that kind of occurs anyway I guess; folks tend to get good at particular niches ... and teams tend to figure that out and dump that kind of work on them. But I don't think the idea of just letting people pick their tasks would work at all ... it would be chaotic, potentially lead to negative confrontations and could not in any way guarantee that all required jobs would be covered.

The person you insulted probably works somewhere turning out software that accomplishes exactly what the client asked for it to accomplish, produced in such a way that the developers were likely paid well and receive production bonuses upon efficient delivery. If you use other esoteric metrics to measure the success of a project ... well, I guess that's why you probably aren't a manager.

I think there's a lot of good arguments for doing rotation, but the management needs to understand that the transaction costs are going to be higher. First of all, the success of such a plan requires iron-clad conventions. Naming conventions are important, but even things like judgement calls for MVC separation vary all over the map. Getting conventions and standards in place requires time and constant administration. Most shops just want things done now, now, now.

Let your programmers choose which project they will work on. Since most of them are glory hounds, they will tend to spread themselves out. It's better to be a big fish in a small pond,... But what if there's a project nobody wants to do? Well, can your company live without it? If yes, drop it. If not, present it as a challenge and a chance for glory.

Unrealistic. I have to develop on the projects that are contracted and funded. I'm not going to let primadonnas dictate what succeeds or fails for lack of attention.

Micromanagement does not work. Nor does letting your sales staff decide what is doable. Your company turns out barely adequate software.

I hope you put more logic into your coding than you did into this (assuming you code). In the business model apparently being discussed here, sales staff negotiates what the client is willing to pay and what they expect for their money. Ultimately the *client* decides what *must* be done (assuming you intend to honor your side of the contract). Management is responsible for organizing the resources to ensure (a) the sales folks don't screw up and (b) that the development team gets the job done while returning a bit of profit to the organization.

It's not really possible for someone sitting in the developer's seat to have all required information to make strategically sound choices on a vast array of issues - if the point is to have a successful company.

Your scenario envisions taking a hands-off approach to the point of being non-management. To-whit, the manager just says "fuckit, you guys decide what you want to do ... and we'll just watch and see what happens." To a *degree* that kind of occurs anyway I guess; folks tend to get good at particular niches ... and teams tend to figure that out and dump that kind of work on them. But I don't think the idea of just letting people pick their tasks would work at all ... it would be chaotic, potentially lead to negative confrontations and could not in any way guarantee that all required jobs would be covered.

The person you insulted probably works somewhere turning out software that accomplishes exactly what the client asked for it to accomplish, produced in such a way that the developers were likely paid well and receive production bonuses upon efficient delivery. If you use other esoteric metrics to measure the success of a project ... well, I guess that's why you probably aren't a manager.

Not going to register (or do I have to buy it? well not going to do either of those) to read the rest of that article, but does that article actually substantiate its claims by listing a few successful larger software companies (say 50 devs or more) that actually doesn't have managers?

If not, while I do enjoy people with no practical experience arguing how much better everything would be if we just followed their ideas (for a technical example see Tannenbaum and his microkernels, cute idea in theory, in practice not so much), it'd be much more reasonable if they would just demonstrate their clearly superior model instead of just talking about it.

Actually the first thing I find about the author of this article is his praise of Enron in 2000 (!) for its "revolutionary strategic innovation". So yeah we clearly have an expert with great judgment here.

That said how much management is necessary depends to a large degree on the company, Valve has a fairly laissez-fair model of management and it works quite well for them. But even Valve has quite a few managers, because in the end you need someone to coordinate work and communicate with other teams.

I have the luxury to develop my code on my time. Rotating works for code maintenance and little jobs. But development of big projects removes me for weeks from reality leaving me unable to concentrate on anything else until the code works.Big projects need a level of dedication to details that rotating would be impossible.

You will have excellent programmers with an awesome grand vision... but no reason to try. They'll be part-way in and have their dreams dashed as they *lose* their project to who-knows-who. You'll have horrible programmers that are apathetic, again, not much of a reason to try because there isn't much accountability / incentive.

Personally, I wouldn't work at a place that does this, and if my company switched to this scheme, I'd be putting in my 2-weeks pretty quickly. No way I'd let me babies be dashed on the rocks.

[edit]

... and all of this is best case scenario: assuming all of your programmers have a decent level of skill (often not the case) and they're all capable and willing to write well-organized, well-formed software using good naming conventions, etc, etc, etc.

The other problem is more a personnel management issue, often described using terms like "bus factor". The idea is that it's bad for any project in an organization to rely so heavily on one person in case they get hit by a bus or get a better offer somewhere else. But while that may be a problem for an organization, intentionally trying to devalue an employee's contribution doesn't seem like a very good way to create much employee loyalty. It's emphasizing that the organization would like to be able to treat the developers like a bunch of interchangeable cogs in a machine as much as possible. That might be true, but it seems like a poor idea to make it so obvious.

Do you know what it's like to be spending a day with your family, when the boss calls you and says there is a bug thst has to be fixed RIGHT NOW or else the company is going to loose $300,000? I've had calls like that.

Sure, they can't force you to cut all your plans and drive to the office immediately to spend ~15 hours fixing the bug with no breaks. But they can, and will, transfer you to a position where you are never allowed to work on anything important/interesting again.

It is far better for everyone, including the employee, if multiple people are familiar with the codebase. If a second person is available then you won't even hear about the bug until you get back from your break.

This should never be allowed to happen, and it does not require cross-training to prevent. Both the team lead and the person under them responsible for a particular piece of code should be able to fix it. The lead should be familiar enough with the overall application to step in and fix bugs if the "ideal" team member is not available. The only exception is if it's a one-person team, but even then there should be a lead that oversees things along with one or more other projects if possible.