6 reasons you should NOT rotate developers onto new projects frequently

I believe that there are a lot of good reasons to rotate the developers at your company onto other projects more frequently than you already are. What I mean by “rotate” is that a team member is effectively moved from one project to another. This is usually in the form of a trade. A developer from one project switches places with the developer of another project. They’re still around to help anyone working on the old project, but it is no longer their primary roll.

Just how frequently am I suggesting that developers should rotate onto new projects? In my opinion, a developer should be on a new project every 6 to 12 months. But this is something your company should experiment with to find an ideal length of time.

I wrote about the benefits in my previous article. I don’t want to act like this is all advantages so in this article I’ll be pointing out the downsides:

Developers may not see the ramifications of their choices

I’ve worked with people who I would say rotate onto new projects too frequently. As a result, they never were able to see the ramifications of their choices. They may have pushed hard for a new pattern of testing that did not work out well in the end. If they stayed on the project the whole time, they would feel the pain of choices and learn from their mistakes. If rotated too frequently, they may never see the problems that were caused.

This is why I suggest a rotation time that is long enough for people to see the ramifications of their choices but short enough so that developers can learn new things and share context before it’s too late.

Frequent rotation can make people stop caring

Even if developers are rotating from team to team, that developer should feel a sense of ownership of the project while they’re working on it (even better, the whole team should feel ownership). If you rotate developers too frequently, they may not feel responsible for the project they’re working on. They may feel like guests in the code base instead of owners.

This problem can be exacerbated if a deadline is given and the developer knows they are rolling off long before that deadline.

I would say this is a good reason to plan a rotating schedule around events instead of instituting a schedule around time.

The rotation may come at a bad time

There’s rarely a perfect time to rotate developers on and off a project. It may be disruptive to the team or the individual. This is why it’s important to share context properly before anyone is rotated on or off a project. Without this upfront effort, the rotation is going to cost a lot more than it needs to.

It takes time to share context

When a developer moves to a new project they now have to become familiar with the code base. This costs time and therefore money. The rest of the team also has to slow down to communicate concepts to the new developer that they are already familiar with. I’ve written about ways to reduce this cost, but it can’t be eliminated.

This is another reason you should avoid rotating too frequently. But, there is a time where the cost of sharing context is worth the risk of a small bus factor number.

Developers may like “owning” a project

A lot of developers consider their project their baby and don’t like the idea of anyone but themselves working on it. When one is in this state of mind, they are not going to appreciate being rotated off their project. Therefore, rotating onto new projects regularly will demoralize these developers.

Rotating onto a low quality project is not fun

If nobody rotated to different projects, each project could stay as its own island of quality. Some would be high quality and some would be low. But if you were working on a high quality project and you rotate onto a low quality project, this can feel like a downgrade. Of course, others may see it as an opportunity to improve the quality of a new code base, but most developers don’t consider that to be a pleasurable experience.

If the rest of the team has a low bar for quality, it can feel like one against all if the new developer tries to improve the code base and nobody else sees a problem with it.

The best way I’ve seen to deal with this problem takes a few steps. First, you must identify a project as low quality and another project as high quality. Then, half of the low quality team should be rotated with high quality developers. This way, it’s not a one against all situation anymore but there should be enough people left on the low quality project to share context. I suggest this because it is really difficult for one person to turn the tide against a whole team.


Although I feel like most companies should rotate their developers onto new teams every 6-12 months, I do acknowledge that this comes at a cost. With these tips, you can avoid the pitfalls of rotating too frequently, at the wrong time, and rotating between projects of different quality.

8 reasons you should rotate developers onto new projects regularly

I believe that there are a lot of good reasons to rotate the developers at your company onto other projects more frequently than you already are. What I mean by “rotate” is that a team member is effectively moved from one project to another. This is usually in the form of a trade. A developer from one project switches places with the developer of another project. They’re still around to help anyone working on the old project, but it is no longer their primary roll.

Just how frequently am I suggesting that developers should rotate onto new projects? In my opinion, a developer should be on a new project every 6 to 12 months. But this is something your company should experiment with to find an ideal length of time.

I don’t want to act like rotating developers is all advantages. But I shall discuss the disadvantages in a future article. Here’s why you should rotate your developers onto different projects:

Rotating developers helps them understand the big picture

Lets go extreme and imagine that one of your developers worked on every single project at your company. They would be intimately aware of how all the pieces fit together. They’d understand why a request to another team is reasonable or unreasonable given their constraints. They would have insight into the best place a feature to be implemented and be able to break down high level requirements into low level stories that are distributed to the rest of the teams. And, the chances that all the pieces would fit together in the end would be improved.

Consider that not all projects are user facing. Some projects are merely APIs for other projects. The people stuck on these API projects have a difficult time seeing how the features they are writing are providing value to the end users. Rotating these developers onto user facing projects will give them empathy for the customers and help them make decisions on their behalf. This decision making advantage will carry oven even if they are rotated back onto an API project. If a developer from a user facing project rotates onto an API project, they can bring a lot insight to the rest of the team for the same reason.

Rotating helps with a shared context

There’s a company maturity level required to even be able to rotate a developer from one project to another. Unless there’s a good support structure (documentation, onboarding, pair programming, etc.), a rotation will not go well. This support structure requires a way to share context. Without this – worst case scenario – it will be as if both developers quit. This would occur if you only had one person teams and after rotation, the two people never communicated with each other. Without being able to share context about where they left off, the ramp up time for being effective on their new projects will be astronomical.

The reality is that any developer is free to quit any time they want. So avoiding rotation does not avoid this concern, it just stops you from dealing with it until it’s too late. Better to deal with this risk head on today than at the worst possible moment tomorrow.

Rotating increases collaboration

With a large enough company it can become possible for projects to depend on each other with limited collaboration. This is a problem and here are a few symptoms of it:

  1. Work that is frequently blocked waiting for other teams
  2. Components that don’t fit together (e.g., an API nobody uses)
  3. Features that nobody uses

Frequent rotation will help alleviate these problems. It will also give developers direct contacts with people in other projects and that can pay off in unexpected ways.

Rotating empowers anyone to fix issues on any project

Once a developer has worked on a project, they will feel comfortable fixing issues on that project. When a company does not rotate developers this is not the case. When a project has production issues the developers of other projects wait for the developers of that project to fix it. This doesn’t have to be the case. With sufficient trust and collaboration, any developer could feel empowered to fix any production issue regardless of the project.

Rotating can reduce employee churn rate

A lot of developers start to look for a new job when they feel their current job has stagnated. It’s no fun to know everything you’re going to do day in and day out for years to come. Another reason developers quit is that they want to work with new people or learn a new technology. Rotating gives a developer all of those opportunities with very little downsides (relative to having an employee quit).

Some projects are less fun than others. If a developer is stuck on a bad project and it feels permanent, they’re likely to look for a new job. But if a new project is 6 months away, the bad project will be temporary and an employee is more likely to stick it out.

Rotating is an opportunity to learn

Having a developer stuck on a project for years is like having a developer live on a little knowledge island. They are learning things that would be valuable to share with others. Others are learning things that should be shared with them. When the organization structures these communication boundaries so developers can’t share experiences, everyone is left to their own devices to learn.

This is inefficient because some islands that others have already learned. Some islands may never learn a lesson that they should.

Rotating gives developers an opportunity to improve code quality

I’m working on a project right now that has had over 4 people rotate on. Each time a new person rolls on, they point out a low hanging fruit for improving the quality and stability of the code base in their first week. Why does this keep happening? Because a pair of fresh eyes can easily see the eyesores that the rest of the team has learned to adapt to over time.

When developers know they will be rotating onto new projects and responsible for sharing context before they leave, they’re going to be encouraged to write maintainable code. It’s far too common for a developer to silo knowledge so that nobody can understand it but them. Frequent rotation reduces this risk by addressing it earlier.

Rotating can reduce ego

Pride can be a good thing when it improves code quality. But ego can get in the way of code quality and cause developers to silo the knowledge of their project. Frequent rotation reduces this problem to a 6 month period because that’s the longest that an individual can “own” their code. I’ve discussed in other articles why code ownership is a bad thing.

I will say that there are more effective ways to deal with this issue (pair programming comes to mind).


Hopefully these advantages have convinced you that your company should be rotating developers onto new projects more frequently. Feel free to reach out to me if you have any questions or concerns.

I’m OK with some DRY violations. Here’s why

If you haven’t heard of DRY, it stands for, “Don’t Repeat Yourself” and it says “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

I first learned about this principle in The Pragmatic Programmer and immediately connected with it. I think the reason why is that it was so easy to apply compared to all the other software engineering principles. Most principles are very abstract but this one is easy to follow. When you see two methods that are similar, combine the methods into one and both places should use the single method.

The benefit of fixing DRY violations is that if the code is copied and pasted in two places and then you discover a bug in one place, you may forget to fix it in the other place. You spent all the time fixing it the first time and now you’re going to spend all this time fixing it the second time. Bugs are very expensive and this could have been prevented the second time if you DRY’d up the code. Even if you realize you need to fix the bug in two methods upfront, you still have to put in the effort to fix it twice.

Also, we spend much more time reading code than writing it. If there is duplicate code, there is even more code to read to understand the code base.

But, I rarely find two identical methods. Usually it’s more that two methods are a close match instead of an exact match. To merge the two into one, I have to add a flag on the outside to say conditionally skip a part of the similarities. Or, I have to extract a part of one of the methods and that new extraction is now a match with another method.

Don’t get me wrong. This often has a lot of benefits. But, these little compromises make the code slightly more complicated. It’s even worse when the functionality of the DRY’d method now needs to diverge in different ways depending on who’s calling it. Sometimes this works out, but other times you wish you were working with two different methods instead of one shared one. In my experience, it takes a long time to realize that a merged method should really be two separate methods. And until you figure this out, the code tends to get much more complex than it even would have if you left the methods as duplicates.

Lets summarize so far: DRY violations are bad because they increase the size of your code base and can be a cause of bugs. But when you fix these DRY violations your code can also become more complicated and therefore difficult to read.

When I’m practicing TDD (Test Driven Development), DRY violations are low on my list of things to deal with. When you’re practicing TDD by the book, these types of bugs are usually caught by a failing acceptance test. An acceptance test tells me if the feature works or fails. That gives me the luxury to keep the DRY violations around for longer than I’d feel comfortable with in an untested code base even if the bug is duplicated in two methods.

TDD also tends to increase code quality much more than fixing DRY violations does. It’s a false dichotomy, but if I had to choose TDD over fixing DRY violations, I’d choose TDD. This is why I’m comfortable leaving DRY violations around unless a test is driving me towards fixing them.

That’s why there’s a guideline we go by where I work. We avoid fixing questionable DRY violations until there are 3 duplicates. With a well tested code base, the advantages of fixing DRY violations don’t necessarily outweigh the disadvantages. That’s why we often wait and see.

6 effective ways to deal with Brooks’ Law

Frederick Brooks wrote in The Mythical Man Month that “adding manpower to a late software project makes it later”. This is also known as Brooks’ Law. One of the reasons for this is that each time you add more people to a project, the communication overhead increases.

Here’s why: Imagine your entire team needs to work on a new feature. To be able to work on that feature, they need to understand what to build and how to coordinate building it. This requires sharing context. When you have a team of one, that team member does not have to communicate with any other team members. When you have a team of three, there are three people that need to coordinate. But if you increase the team to eight people, there are twenty-eight paths of communication to make to coordinate work. This image from a stackoverflow post explains the concept well:

"Communication Overhead"

Obviously there are advantages to having teams larger than one, otherwise every team would be a team of one. A team of one has to wear many hats. For example, a developer will have to gather requirements if a product manager is not doing it on their behalf. That might make sense sometimes, but any time spent gathering requirements is time not spent developing. It almost always takes more time to develop features than to gather their requirements and not everyone can develop. Therefore, the team as a whole would produce more if the developer(s) could spend their full day developing.

There’s also the issue with the bus factor. If a team of one quits or gets sick, progress abruptly stops. If there are multiple developers with a shared context, the others can fill the role of the absentee.

So how do you know when a team is too large and should be split? That’s not an easy question to answer. Obviously if developers are spending more time communicating than developing, the team (or its boundaries) are too large and should be split. And if the communication overhead negates the benefits of a larger bus factor number, the team should be split.

I don’t have better heuristics than this, I’d like to hear your ideas. But, I do have some suggestions on reducing the cost of the communication overhead.

Clear goals and requirements are a must for the project. For example, each developer should know “why” they’re building the feature they’re building. If they don’t, they can’t read between the lines when requirements are vague. They’re going to have to communicate more to get clarification. Or, they’ll end up building the wrong thing and have to communicate more to build the correct thing later.

It helps if the team is working on a complete bounded context. If you’re unfamiliar with the phrase, that article should help and so should this image:

"Bounded Context"

Imagine your project encompasses two bounded contexts like the image demonstrates. You’re going to frequently need to clarify which “Customer” and “Product” you’re referring to. That’s going to slow down communication.

It’s also important for the team to own a complete bounded context. If team X owns half of the Sales Context and team Y owns the other half, they’re frequently going to step on each others toes. Coordination will require a lot of inter team communication. This should also be considered when you’re thinking about how to divide a team that’s too large.

Another way to reduce communication overhead is to come up with a ubiquitous language. This means that when you’re working in the Sales Context, everyone is on the same page as to what a “Customer” is. This also means that the team agrees it’s called a “Customer” at all times. It’s not called a “User”, “Guest”, or “Patron” sometimes. This agreement will reduce the time it takes to communicate concepts. To learn more about Bounded Contexts and Ubiquitous Language, you should read Domain Driven Design.

Communication can be greatly reduced if there’s a communication gateway: A person where a lot of communication flows through so that everybody doesn’t need to communicate with everybody else. For example, if the Product Manager is the “requirements master” and that’s known to the team, I don’t need to ask the rest of the team for clarification of requirements. I can just go directly to the PM. I wrote more about this in my article titled, A Good PM is a Communication Gateway.

Last and least, if everyone has a high level of skill, the need to communicate is reduced. Imagine a new team member joins that doesn’t even know how to use the programming language of the project. A lot of communication will be required to catch that person up to speed.