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.

Step 1: Developers Agree to Deadlines

Imagine you wanted someone to build you a house and they told you that it would take a year to build. “Unfortunately”, you tell them, “I already told my family that we’d be living in our new home in 3 months”. Of course they tell you they can’t build it on such an aggressive timeline. But, lets say, hypothetically, you had the power to convince this person to agree to your deadline. Would you feel comfortable living in that house?

Imagine the amount of corners the builder would have to cut to meet your deadline. Building a house that way would probably break all sorts of laws. Yet, we do this on a regular basis in software: A manager tells developers about a deadline that they don’t believe they can meet and the development team has to scramble to try to meet it anyway.

Developers have to have a say in deadlines or you will never be able to build high quality software. This is step 1. I don’t use the phrase “step 1” lightly. I literally mean that this is the whole foundation that quality software is built on top of. You must tackle this first.

If developers don’t have a say in deadlines, any attempt at quality will be undermined by unrealistic schedules. Corners will have to be cut to meet these deadlines (AKA technical debt), but the developers will never have any time to go back and pay off this technical debt. Quality can only get worse in such an environment. No process, including Agile, can overcome this.

The only people that know how realistic a deadline is are the people that know the inner workings of the project: The developers. And if they aren’t involved in setting deadlines, an unrealistic deadline will be picked most of the time. That’s because, all things being equal, delivering a feature sooner is better than later.

Now you may be asking, what if the developers don’t agree with the deadline? At this point the managers and the developers should negotiate.

One thing to negotiate on is scope. e.g., “What if the building didn’t have AC by the deadline but we installed it later?” This often goes back and forth many times as the manager and the developer come to some agreement.

Another thing to negotiation on is the deadline itself. e.g., “Realistically, we’d probably complete that 2 weeks after the deadline. Is that ok?”

And third, quality can be negotiated on. e.g., “These windows are poor quality but they’ll save me a ton of time to install at first. Then we can go back and put some better quality windows in later.” Technical debt is an example of this. But quality can only be negotiated on if there is trust between management and the developers. The trust needs to be that the developers will be allowed to go back and put some better quality windows in later.

By the way, this shouldn’t be unquestioned trust. The manager should ask why the developers won’t meet the deadline. Maybe the developers will say, “Because it takes 5 weeks to lay a foundation for an apartment complex”. Then the manager could say, “We don’t need that. We only need the foundation for a single family home”. This communication is very important.

But, this whole system falls apart when developers have no say in deadlines. The end result is poor quality software every time.

6 dos and don’ts for using an outside agency to write your automated tests

Companies often know they should be writing automated tests but “don’t have the time”.  As a result, they may pay an outside agency to write their automated tests for them or assign it to a QA team.  This situation is far from ideal: Developers should be writing the automated tests for their code.  An outside agency or QA team can be used to write more functional, higher level tests as a safety net to that.  I really believe this is the only correct way to do it.  But, if you insist on having an outside agency or QA do it, here are some important dos and don’ts:

Continue reading

“If it ain’t broke, don’t fix it” only makes sense for finished products

If it ain’t broke, don’t fix it: Leave something alone; avoid attempting to correct, fix, or improve what is already sufficient (often with an implication that the attempted improvement is risky and might backfire). –Wiktionary

A lot of developers avoid improving the code they work on and if you ask them why, they’ll say, “If it ain’t broke, don’t fix it”.  I understand their perspective: Every little refactoring could introduce a new bug and they “know” that the code works right now.  Well, in my experience, when people have this attitude their project is usually broken in some way they just don’t know yet.  But, that’s not the point of this article.  The point of this article is that the, “if it ain’t broke, don’t fix it” attitude only makes sense on a finished product.

You can have the luxury of this attitude when it comes to your car, your TV, or your watch.  When a watch is shipped, if a “version 2” comes out, it completely replaces “version 1”.  Both “version 1” and “version 2” are finished, physical products that do not effect each other.

But, software is a different beast.  Very rarely is software “finished”.  Usually it is actively maintained for years and needs to be changed by a developer constantly.  In this situation, you can’t have an “if it ain’t broke, don’t fix it” attitude because, working or not, it needs to change.

Continue reading

How to easily add a bunch of automated tests to a project that has none

If a code base is well tested and very stable, it’s pretty easy to write more tests for it.  But, how do you get started writing automated tests if your legacy application has none?  It’s very difficult to get started because the code wasn’t written with tests in mind.  Normally, the endeavor will have you pulling your hair out.  This is unfortunate because a lot of untested code desperately needs tests, yet it takes an inordinate amount of effort to write them.  In this article, I’m going to tell you about a tool that you probably haven’t heard of that can help you get that legacy code base tested.  It’s called Approval Tests, and here’s how it works: Continue reading