There’s a famous parable that’s regularly shared at business conferences and it’s about a pot roast. Bear with me for a minute—I swear it’ll be quick. The short version of the story goes something like this:
- A mother and her young child are preparing to cook a pot roast in the oven.
- The mother cuts the ends of the roast and throws them in the trash.
- The child asks, “Why did you do that?”
- The mother says, “I don’t know. It’s something my mother always did. You should call grandma and ask.”
- The child calls grandma and says, “Mommy says you taught her to cut off the ends of the roast before cooking it. Why?”
- The grandmother says, “Because our oven was too small and we had to cut the ends off to fit it in the oven.”
What does this meaty parable have to do with software development? Well, believe it or not, a lot of today’s software development practices continue because computers were much slower and less capable a couple of decades ago. We simply haven’t shifted our mindsets (or codebases) to 2021 and are still carrying the technical debt of backlogs from the days of yore.
One of these legacy dev practices is infrequent code commits and merges to mainline branches. In this article, we’ll discuss why we need to do it more frequently and how to overcome the common obstacles that slow us down.
What’s so great about frequent merging?
In today’s agile-dominated software world, new releases are targeted for production every sprint. (It’s worth noting that some companies release several times a day!) Frequent releases are made possible by small, well-defined commits that are easier to merge into a mainline branch. Such changes are also easier to build and test.
There are so many benefits to merging and releasing frequently. You can respond to the market quicker, A/B test small feature variations, get marketing and sales data faster, build confidence across the organization, maintain user engagement and satisfaction, and development teams can see the impact of their work quickly.
Let’s not gloss over that last point—every developer I know gets frustrated when their code never sees the light of day. Frequent merges and releases have a measurable and discernible impact on developer productivity, well-being, cognitive load, and overall happiness. (Sources: Martin Fowler, McKinsey, ACM)
Merging and releasing frequently come with prerequisites. Test suites must be fast and provide meaningful signals to developers when bugs are discovered. CI/CD pipelines must also be fast, trustworthy, and reliable. Requirements and bug fix criteria must be clear, well-documented, and well-understood. Linear project histories are maintained.
Notice that none of these prerequisites are downsides. Every prerequisite is a symptom of highly-functional and synergistic cross-functional teamwork. Companies embodying the above are high-performance software organizations.
Why don’t we commit and merge more frequently?
Back to the pot roast parable: in the early days of the Firefox web browser, new releases dropped every year or two. (It’s hard to believe, but Wikipedia has it all written down.) It took a lot longer for features to be developed in the early 2000s because nearly everything was slower. Processors were 32-bit, phones weren’t smart, and a third of America was still on dial-up. Feature-based releases were stressful for developers because people were rushing to get features into the once-every-few-months release. If they missed the release date, they’d be waiting months or years to go live.
These infrequent releases were also stressful for customers to adopt and integrate. Every major Firefox release brought new challenges for users and IT administrators. Web browsing was leaping forward with each release instead of taking small incremental steps. Firefox wasn’t the only software facing such challenges, either. Every major software company was beholden to feature-based scheduling.
It’s just how people did software back then.
Fast forward to 2021, when practically every time you launch Firefox you get a notification about an update that’s ready to install. Many software companies have made the leap to agile development practices, but many haven’t. We see it all the time.
Despite the exponential advancement in sophistication of build, test, and release automation, there are a lot of companies still pushing through each day with legacy practices. The symptoms are hours-long test suites, super-complex codebases, and underinvestment in testing capabilities.
The top 3 problems with large commits and merges
There are a thousand potential problems when merging large pull requests, but we think there are three biggies.
Merge Problem #1: Risk of conflicting commits
Every experienced developer has that wide-eyed “oh $#!t” story when they were assigned an 1,100-line pull request. Or the time they hit the green “merge” button on GitHub and there was some indecipherable error that led to a git rebase that took a day and a half to resolve.
In the best case, large pull requests create merge conflicts like we just described. In the worst case, the shiny green “merge” button worked, but it created semantic conflicts that will cause pain down for someone in the future. The code merges cleanly, it even passes build tests, but semantic code conflicts can lead to anything from incorrect results to hard crashes. The only way to prevent semantic conflicts is an experienced developer reviewing the pull request with a fine-tooth comb.
Merge Problem #2: Large commits reinforce a legacy mindset
Large commits and merges perpetuate the “cut off the ends of the roast” mindset. Small commits require people to think of main branches differently. Yes, they require more management and more technology before code gets to the main branch. But developers need to write code today for a better tomorrow.
Small commits require a change in how developers perceive work. There may be a ticket that comes in for a bug fix, but that bug fix might be decomposable into three subtasks. Each subtask should be mergeable into the main branch. It’s a less surgical and a more strategic way of approaching bug fixes.
The mindset shift should be: Take a task you’re assigned and break it into the smallest possible subtasks, each of which can be a push. In our experience, this mindset is the biggest mental roadblock to get past. Rather than looking at tickets as individual tasks, developers need to break the work down into smaller tasks for incremental pushes.
Merge Problem #3: Slow development lifecycle
If you have no test acceleration technology and your build and test process is slow—I’m not telling you to give up or anything, but, like, that’s a helluva struggle.
If it takes three hours to run a build for each change, the idea of more frequent merges is stressful. You need fewer hours-long build workflows in your life, not more. YourBase can help you reduce that time cost significantly, but it’s usually not a quick and easy fix.
From a purely academic point of view, Jez Humble and David Farley’s book on continuous delivery recommends a 90-second test execution time for each build. That may seem like an impossibly-low number to you, but if you can get your test cycle down to something short, the hurdle it presents for merging will quickly come down.
Merge small commits frequently and carry a big stick
Dev teams struggling with large, risky merges are cutting off the ends of the pot roast and throwing away missed opportunities. (Did I metaphor right?) There’s no reason to carry old-school dev practices into tomorrow’s large ovens. (Still metaphoring, in case you couldn’t tell.) The best time to start merging frequently was yesterday, and the second best time is right now.
The benefits of frequent merging should be clear to you by now. They reduce risk of errors and conflicts, they break teams free of legacy mindsets, and they allow for increased productivity and velocity. The real complexity is the challenge of changing the organization’s mindset, updating workflows and automation, and doing everything possible to speed things up.
We at YourBase are building development tools for large code bases and we help our customers solve problems like this every day. Follow Us on Twitter for more development productivity tips!
Top comments (0)