No code is written in stone.
It’s not uncommon to rewrite your own code halfway through an assignment or moments after it’s been submitted either to address new requirements or adjust for some newfound insight.
The term for these rewrites is code churn, and analytics dashboards like GitHub often track those changes against code added in percentages and charts for engineering managers to reference. While it can be helpful in flagging potential defects in the code base or when an engineer is struggling, numbers alone rarely tell the whole story.
At Spruce Up, a company that provides a personalized shopping platform, engineering manager Daniel Leng expects his engineers to do a lot of rewrites. In fact, an engineer’s willingness to rewrite their code and learn from it is something he looks for in building his team. That might mean their churn levels are high, but it’s all in the service of helping them ship products quickly.
“I feel like I'm not learning if I'm not looking back at the code that I wrote six months ago and feel like I can improve it or make it simpler than it was before,” Leng said.
Edward Strickler, who is the lead software engineer at the car maintenance app Wrench, said he hasn’t found tracking churn as a statistical measurement for engineers helpful. To him, it all depends on what code the engineer is rewriting — and why.
“There’s a lot of outside contexts to be taken into account,” Strickler said.
We asked Leng and Strickler about how they identify problematic code churn, and why it matters.
WHAT TO DO ABOUT CODE CHURN
- Understand where to expect code churn, and where it should be avoided. At Wrench, the more integrated a code base is, the less changes should be made in it.
- Rewriting code can be a useful part of the process when a product is in its early stages. At Spruce Up, churn is part of the job, as engineers build new features one day and iterate on them the next.
- Use stand-ups and code reviews to catch the code churn that matters. An engineer rewriting the same logic for a fifth time is a sure sign of deeper issues.
- Documenting best practices in an established code base can be a great way to limit unhelpful churn. Wrench built a wiki to instruct engineers on how to make changes in its payment solution to prevent engineers from making unhelpful rewrites that influence other parts of the system.
- Keep the code base simple. Attempting to future proof code to limit churn only serves to make it more complicated and difficult to change.
DETERMINE WHEN CODE CHURN IS ACCEPTABLE
Defining instances of good churn and bad, even on a situational basis, can help teams cut through the noise and pinpoint when issues may be arising. At Wrench, if an engineer is rewriting the same logic over and over again to add a feature in an established code base, that can be a red flag, Strickler said.
“Measuring code churn could probably lead engineers to write complex or over-designed code, which I think is detrimental in the long run.”
“That’s what we’ve tried to watch for as an indicator that something needs to be improved in the process, whether it’s code requirements or unreadable code,” Strickler said.
EXPECT TO REWRITE AT THE EARLY STAGES
As an early-stage startup, Spruce Up’s engineering team is expected to ship products quickly as the company tries to find its fit in the market.
“Measuring code churn could probably lead engineers to write complex or over-designed code, which I think is detrimental in the long run.”
Leng expects his engineers to experiment, build products and iterate. What’s most important to him is that the code is simple and easy to replace. For that reason, Leng is wary of measuring engineers by their code churn.
“Measuring code churn could probably lead engineers to write complex or over-designed code, which I think is detrimental in the long run,” Leng said.
Instead, he seeks engineers who are humble, which means they're willing to ask questions about their code and look for ways to simplify it. But that doesn’t mean everything is fair game to be rewritten. Spruce Up aims to limit rewrites of its ordering system, which is designed to be consistent as the product evolves.
WHEN DOES CODE CHURN SIGNIFY DEEPER ISSUES?
One of the best places for engineering managers to catch code churn is in stand ups.
During a recent stand up at Wrench, Strickler remembers an engineer who announced that he had been rewriting the same set of logic on the payment system for the fifth time. While a dashboard would have shown a high rate of churn, it was the fact that it all centered around the same logic that served as a red flag.
“When you start digging, sometimes it’s not a problem with code churn but with poor requirements.”
The ensuing conversation shed light on a deeper issue — that the engineer needed more specific requirements to complete their task. Keeping an ear for when projects are stalling can flag situations where there are problems with the assignment, or when the engineer needs more information.
“When you start digging, sometimes it’s not a problem with code churn but with poor requirements,” Strickler said. “So you had logic that was supposed to do one thing and now you realize it needs to do something else.”
For a smaller team like Spruce Up, code reviews and open conversations have helped keep code simple and limit forced churn. Leng said he also encourages engineers to ask for help from peers as they write code.
“You can create good code and make better decisions if you ask questions early in the process,” Leng said. “That leads to better, simpler code.”
DOCUMENTATION IS KEY TO REDUCING UNHELPFUL CHURN
When a code base is complicated and intertwines with other parts of the software, it can be helpful for teams to keep a running wiki of code change protocol to limit instances of churn.
Wrench prefers object-oriented design, where engineers are expected to group logic based on classes and objects, and include descriptive variables and comments to make swapping code in and out simple. But for some code bases, like its payment system, which is complex by nature, making changes isn’t so easy. So, Strickler said the team decided to create a system-specific wiki to indicate what changes an engineer can and can’t make.
“Setting good requirements up front and spending the extra time to think through the process have been the easiest ways to prevent someone from rewriting code and getting stuck on projects.”
The wiki details what features are vital in the code base and provides best practices for how to make changes. Standardizing the process simplifies the decisions engineers working in the complex code base make in what to add or take out, helping reduce unnecessary code churn.
“Setting good requirements up front and spending the extra time to think through the process have been the easiest ways to prevent someone from rewriting code and getting stuck on projects,” Strickler said.
DON’T OVERPLAN FOR THE FUTURE
Sometimes it pays to just keep your code base simple.
While code will always change with each new product launch, Leng has found that the best approach to reducing unhelpful churn is to not try to do too much. Whenever the team has attempted to write code that will lay the groundwork for what they want to add in the future, it’s backfired. Instead, he’s found that keeping code simple and limited to only the most pertinent features for a release makes it more flexible in the future.
“If you can get people into that mindset, we'll ship more product and we’ll learn more about what we need to be as a product,” Leng said. “And that's the most valuable thing for us.”
