Short-lived Branches

tl;sr (too long; still read)

Suppose you have a feature that you’ve estimated would take about 4 days to complete. Monday comes around, and you begin development on it.

Now consider a familiar workflow when developing this feature.

After exploring the requirements and possible designs, you create a branch and start writing some code. By the end of the day, you’ve made some progress, ready to start again the next morning. Tuesday morning rolls around, and you have an epiphany in the shower about a better solution. Getting into work, you begin making some adjustments to the code you wrote the day before. Of course, Monday’s work wasn’t really done with this new thought in mind, so you have to decide whether to put some shims in for your new idea or just keep going with the approach from the day before. Already, a single day in, you’ve got some technical debt built up: decisions that were made at the beginning of the feature are now negatively influencing your design (see Ward Cunningham reflect on technical debt ~5 minute video). But, of course, you keep going. You could take the time to refactor the previous day’s work, but that would take time you aren’t sure you want to spend right now.

Now consider a different workflow.

After exploring the requirements and possible designs, you create a branch and start writing some code. By the end of the day, you’ve made some progress, ready to continue the next morning. Tuesday morning rolls around, and you have an epiphany in the shower about a better solution. Getting into work, you notice the work from yesterday has been deleted, so you create a branch and start working. You re-explore the requirements and possible designs, now influenced by the learnings and thoughts you had the previous day plus the time you had to think in the shower. While the code you written the day before is gone, it only takes an hour, or so, to get back to where you were. You actually end up in a better place, since you’ve had some insights into the design that will make it simpler.

So, what if branches had only a day to live, disappearing each and every day?

I’m going to write up some more thoughts about the effect, but the core idea is that you could accomplish a task in the same amount of time with better code quality.

If you have a task that you think is going to take you 4 days to complete, you could do 1 of 2 things: spend 4 days coding away; or, you can have 3 days to write drafts, effectively exploring the space, then spend a single day writing your final version with much better quality of code based on these 3 spikes.

At first, this seems like a strange, even nonworkable, idea; it immediately feels easy to come up with situations where this absolutely wouldn’t work. For each of those examples that come to mind, I would encourage you to take some time really thinking about it before you form an opinion. If you didn’t have a choice, how would your code and habits change?

I’d like to write more about this idea, exploring the benefits (and dangers), but I wanted to get this out in the world.

To try this, I’d recommend picking a 4-day, non-mission-critical feature and delete the branch every night at the end of the workday. It will be scary the first two days, but I bet you will be excited and happy on the third day. If you do, please let me know either on twitter or email.

I'm a developer. I post pictures of cats on twitter.

Tweet Follow @coreyhaines