Big, long-running feature branches are the worst. They’re challenging to tame, and they slow you down. The odds of bugs slipping in under the radar are high. Each time you return to the project, you need to load an increasing amount of information in your mental RAM to return to flow. Merge conflicts stack up.
Over time, you feel less and less confident in the code. When you ask your teammates for code review with multi-thousand line diff, you’re likely to get a quick “looks good to me!” rather than a thorough assessment.
Not all projects are inherently small, but you can always break them down into smaller chunks.
We recently built a SavvyCal feature called Workflows, which allows you to send emails at specific points in the meeting lifecycle. This project was a multi-month effort that consisted of 92 tasks! On day 1, we began shipping pieces of this feature to production.
Right out of the gate, we added a “Workflows” page to the navigation and tucked it behind a feature flag (visible only to admins).
Then, we created a few database tables to store workflow records and deployed those migrations.
Shortly after, we shipped the ability to create workflows and see them on the index page. Of course, workflows couldn’t do anything yet, but that’s a concern for a later time.
Next, we added the ability to attach a “send email” action to workflows. We couldn’t send the email yet, but we’re one step closer.
Then, we added a way to attach a workflow to a scheduling link.
Each incremental task brought us one step closer to a functioning v1. By shipping these tiny branches to production as we go, we became increasingly confident in the “bones” of the feature. As soon as a slice of the project was ready to test, the whole team hammered on it in production – an effective way to tease out bugs and rough spots in the user experience.
The benefits of this approach extend beyond the ability to QA test as you go. Shipping small parts early on builds momentum for everyone on the project. Getting incremental changes on the main branch and into production frees your mind from trying to hold all the context for the overarching project. Merge conflicts become rare. Peer reviews are quick and effective.
As the feature starts to take shape, you might even identify areas of scope that you can cut. That complex flow you initially mapped out may no longer apply now that you’ve had a chance to put your hands on a production prototype. If the feature feels good earlier than expected, it may make sense to start enabling the feature flag for some real customers to get their perspective.
Next time you’re staring down a daunting initiative, consider busting it apart into little projects and shipping as you go.