One important practice we employ at Atomic is developer rotations. This provides benefits for the longer-term success of the project and keeps our developers at the top of their game.
While you might assume that long-running project teams, living with the project through its conception, implementation, and maintenance, might be the most effective approach, I’ve found the opposite to be true.
Implementation
At Atomic, we try to rotate developers every six months to a year. We will keep most of the team, but one or two existing developers will rotate off, and one or two new developers will replace them.
We make sure enough people remain on the project who are familiar with the client and problem space to keep things running smoothly and get new people up to speed quickly.
Documentation Review
The first big benefit we get is a chance to put our documentation to the test. Like with software, the best way to evaluate documentation is by putting it to use.
An important goal of every project is to eventually hand it off to our clients. We want the project in a state where any future devs continuing our work can hit the ground running. By bringing in someone fresh and having them bootstrap the project following the docs, we could get immediate feedback on whether we are achieving this objective.
We try to always let new devs get as far as they can on their own, with a more familiar dev always available for questions. Any questions we encounter along the way are taken as opportunities to improve our documentation.
Architectural Auditing
Documentation is not the only aspect of a project that needs to be constantly tested. A major factor in the long-term success of a project is the architecture.
One key to building software that’s easy to maintain and expand on is an intuitive system architecture. When you have been living in a system for a while, especially one you have built, it can be tough to assess its merits objectively.
By bringing in someone new and seeing how well they can understand the decisions made and where the project is heading, you can see how good a job you did of architecting it. The earlier you get this feedback, the easier it is to adjust when complexity starts to creep in.
Gathering Fresh Insight
Along those lines, new developers bring in new perspectives. As any jigsaw enthusiast can attest, sometimes you need to go sit on the other side of the table. For software, this means looking at the problem without all the context and assumptions that have built up.
It’s nearly impossible for a developer with a deep understanding of the problem space and months of familiarity with the project to change their perspective. But, it’s surprisingly easy for someone new to come in and point out an angle that everyone else couldn’t visualize.
Familiarity Breeds Complacency?
On the topic of familiarity, another crucial problem can arise when the same people own a problem for too long. They become complacent.
I don’t mean this in the sense that they are lazy, but instead that they understand the problem too well and no longer see the challenges it presents. These developers spend a long time grappling with the intricacies of the problem space and start to take for granted the amount of context they have and the assumptions they’ve made.
This is where bringing in a new developer can be such a boon. Seeing how well the solution makes sense to someone coming in with a fresh set of eyes reveals just how much you’ve been taking for granted and what’s going unaccounted for.
Building Diverse Expertise
One benefit that might be a bit more obvious is for the developers themselves. At Atomic, we pride ourselves on being full-stack generalists who can tackle any technical problem we come across. A big part of this is gaining experience with a variety of problems with different teams and tech stacks.
The most effective way to develop this skill is by getting hands-on experience. Introduce developers to the habit of dropping into a new problem space and hitting the ground running. This allows us to keep learning and continually hone our craft.
Preparing for Change
Lastly, it’s important to remember that we live in the real world. While we like to imagine our teams will be around forever and change will happen slowly, that’s rarely the case.
Instead of waiting to be forced to make a drastic change, hoping you are ready, make the change yourself while you have the safety net of subject matter experts around in case you need them.