Evolution of a codebase

Cover photo by Austin Chan on Unsplash

Every change needs a champion! Any change in your codebase that impact lots of files or mean new tools should always have a champion to keep everyone on track and educated. They can be or organise facilitation, mediation, decisions, and manage impact with the management staff.

Change can happen in a few ways. The big rewrite is a terrible experience. Engineering needs to line up with a big shift in the product or non-engineers sit on their hands until the codebase works again.

Alternatively a few people (or a single person) decide a new way of doing things but not everyone is aware. Unless they review every PR until everyone knows, the old way will keep being used. Someone new starts and they look for what the newest code is that gets something done. They use the old way cause someone is still using it. Now lots of confusion and maybe ego and fighting is going on.

The change should always be incremental, team-focused, and championed. It requires consensus, cultural considerations, handling of the legacy, possibly codification, and most importantly education.

What does a Champion of Change do?

Photo by Ross Findon on Unsplash

A champion ensures the change is incremental and team-focused, that there is a consensus, that the culture is considered, that we make plans for legacy code, how to make it codified, and handles the education.

They can't do that alone. Champions of Change are the people that when any change that's foundational or widespread is planned they manage it. If a team discussion needs to happen, they organise a facilitator, or if management needs to be chased to plan time in time for kick-off, each champion will do this for the change their heralding.

They also understand why we're making the change and embody the team. A champion will represent the team and what they're trying to achieve along with how and why these changes are good for the goals of the team.

Becoming a Champion

Photo by Johnson Wang on Unsplash

A champion should be the person who rallied the consensus that the team changes something. One of the best ways to do this is to ask the team for a short period of time to create a PR to display what the change is and do a few other small things like update linting configurations and preparing automated code transformations that help codify the change. Make sure that PR description contains:

• How the change helps achieve the team's goals (faster, cheaper, improved quality, etc.)
• How to handle legacy code (use code transformation, incrementally using the Boy Scout rule, etc.)
• Examples - What code look like now vs what it did look like (use commit diffs from your PR and simplified examples to show concept and in practice)
• Decision deadline - your team should work out a default like 24 hours

The team now votes and comments on the PR until the deadline is reached or there is an obvious outcome. In that time it's ok to make minor tweaks based on comments and feedback. If there are any major changes make sure to close the PR and create it again with a rewritten description and new deadline.

Any feedback you get you must always default to the side of agreeing with it and working with that person to check it against the why and team goals. If it doesn't align with the purpose there may be another change hiding that person can champion. You want to aim to walk anyone participating through the process and goals.

Make sure while this is all happening to keep rebasing your branch from the primary development branch.

Championing an approved change

Photo by "My Life Through A Lens" on Unsplash

Your team has approved the change, the first commits are in, and your lint rules are updated. Potentially a code transformation has been applied to the codebase. Things get much harder now as it's time to change everyone's habits and protect the codebase from old methods and tools sneaking being used.

Talk to the top PR reviewers and people who pair. These are the people that are talking to most of the team. Focus your attention on educating them, pairing with them, and making them spokespeople for the change. Throughout their reviews and pairing, they'll spread it to the rest of the team. They can tag you on a PR if you need to review an edge case or some confusion.

Hey X, you're always working so well with the team in your reviews and pairing, you would be a big help to the team if you could help promote the new changes to X. The description of the change is here: LINK

If there's anything you want to ask me or if anyone has any confusions or finds edge cases we didn't consider you can loop me in and I'll help too.

A simple message like this can bring someone on board to be a helper that will begin to change the culture around the change. Make sure to say why you think they'd be helpful and to give them the information they need.

Time to improve!

Photo by John Baker on Unsplash

Now that you know all this, have a chat with your team about using Champions of Change. Throughout all of this keep in mind that being a Champion of Change takes effort and will mean pairing, chasing people up, keeping on top of dates, and making sure to have check-ins. It's not a throwaway title.

Before you or anyone in your team takes on a change to champion you should always talk to the timekeepers in the team like your manager or project manager. If you specifically are going to be too involved in something it might need to be passed onto someone else or delayed if no one else is available. It's better to keep doing the existing method than to take on more than you or the team can handle.