De Voorhoede

front-end developers

Get high team morale, quality code, and fresh thinking by rotating developers frequently

How to keep your projects fresh, and clients happy

We like to keep our projects fresh. When one of our developers has worked with a client for six months straight, we rotate them out and replace them with a colleague. But how to deal with consistency of quality, knowledge transfer and such?

Substitution of two football keepers during 2014 World Cup match
Jasper Cillessen, playing for the Dutch national team against Costa Rica in the 2014 World Cup, is substituted by Tim Krul who went on to stop 2 penalties. Photo credit: Henk Jan Dijks/ANP

Developer rotation boosts energy, motivation and fresh thinking

We have at least three good reasons for developer rotation.

  • Rotation boosts energy. Solving new puzzles and learning new concepts is what makes a developer’s juices flow. New energy keeps any longish project vivid.
  • Rotation boosts morale and motivation. ‘Educating’ new members in the team is a great way to solidify, share and gain knowledge. As much for the leaving members as the new ones on the team.
  • Rotation guarantees fresh thinking. New team members add new ways of approaching old challenges. New perspectives are the source of better solutions.

Now, let’s look at how.

Embed knowledge with good communication and code conventions

Before the new developer rotates in, there’s a couple of things you should do to pave the way:

  • Make developer rotation a known policy. By making developer rotation a standard part of the way you do your projects, it becomes easier to communicate it upfront. Meaning: in the proposal. That way rotation will never come as a surprise to developers and clients.
  • Plan precisely. Start planning the rotation well in time. Usually we start planning two months in advance. That way we have time to match the right developer with the job at hand. Plan at least two weeks for a proper handover from developer to developer.
  • Document your code well. Documentation is the key to working collaboratively. At De Voorhoede, we tend to document basic implementation details, APIs, and quirks that deserve special notice. We put a README next to each component that explains its purpose and how to implement it. For code that's hard to comprehend, we include JSDoc-type comments. We don’t overdo it; most code should be self-explanatory. Don’t be careless about documentation or it will come back to bite you!
  • Put a README in the root. This file should be the common source of knowledge for everything in and around the code base with regards to writing, testing, running and reviewing code.

Now that the code base is in pristine condition and everybody knows the supersub is coming, they can be eased into the project:

  • Do a social introduction. Show the new colleague around the work floor. Explain who’s who in and around the project. Remember in particular to explain everyone’s goals and agenda’s.
  • Current state of affairs. Every project has some rough edges, either in the technological stack, due to flawed processes, or coming from management decisions. These things are usually undocumented, but important for the new developer to know about. If the developer who is rotating out is still dealing with these situations, they should pass on critical information and point out who to contact, so that the new developer can deal with any escalations promptly.
  • Go over technical project details. Walk through the build process together. Point out what technologies are used and explain the choices that were made. Show how tests should be run, how to file bugs, create fix patches and how to deploy your code.
  • Demo the current working version. Explain the project objectives while demonstrating the current working version of the project. Objectives and choices get the proper context in that way.

Almost done! All that’s left is cleaning out the desk and shake up the pillows:

  • Leave a clean sheet. It is common courtesy that every developer finishes their tasks before leaving. A proper handover period certainly helps. In some cases, if a task is too big to be completed, build an MVP and document a set of improvement issues for the new developer.
  • Be around until everything works. Your new colleague should set up the project themselves, which is a good test case for the README’s completeness. Apart from that, help with troubleshooting e-mail accounts, JIRA access, entrance passes.
  • Run!

In conclusion: fresh developers means fresh code, motivated developers and happy clients. If you found this interesting or you’d like to work with us, just drop a line. We’re always interested in new people and new challenges!