Corey Haines (@coreyhaines) wrote an interesting article on something he’s calling short-lived branches.  The short version is: Corey observed that we sometimes think of better ways to code something after we’ve started, but won’t start over (in economics this is called the sunk cost fallacy).  The end result is code that could have been made better, but wasn’t.  Corey proposed deleting your source control branch at the end of every day to force the restart of all feature effort (removing the decision about whether to start over or not), and hypothesizes the feature will be finished with higher quality by going through a “draft” process.

Most developers are familiar with the “two codebases effect” that arises when coding – having the code they’ve written, and imagining the code they wish they’d written.  Fred Brooks, who is probably most well known for Brooks’s Law – “adding more people to a late software project makes it later” – also observed “plan to throw one away, you will anyhow” all the way back in 1975.

Not all features suffer from this uncertainness of design though.  Often a code base will have well established patterns in place with one fairly well understood method of implementing the feature. If you’re working on a medium to large sized line of business application and you need to add some maintenance screens (add a widget, edit a widget, delete a widget) for the 42nd business concept in the system, you’re not likely to get any benefit from going through a draft process.  In these scenarios, writing it multiple times would simply be a waste of your time and your client’s money.

When features do need a design pattern that’s not already present, there’s definitely value in exploring different designs.  One good way to do this is with quick prototypes (some agile methodologies such as XP call them “spikes”).  Prototypes are intended to validate a particular approach or explore various design options within a short time period.  They aren’t built to production quality so they can be completed in a small timeframe, and are thrown away afterwards.  This allows for rapid iteration of design ideas without the pressure to “get it right”.  When doing prototypes it’s important to communicate to everyone else, and especially your manager or client, that the prototype is a fragile, temporary thing destined for the trash can and to resist any pressure to “just use the prototype” afterwards.

My initial reaction to one day branches is skepticism of the value it brings.  You’re taking on the guaranteed cost of rewriting code multiple times for the possible benefit that by doing multiple “drafts” you’ll get a higher quality implementation.  However, I had the same reaction in the past when a coworker excitedly told me about Test Driven Development.  We learn by trying, and I’m curious to see how the short-lived branch experiment turns out in Corey’s future posts on the subject.

Regardless of the approach you use when writing features and software, it’s inevitable that you’ll perceive better ways after you’re done.  Indeed, you’re lucky if you only think of better ways to implement single features – often the entire system architecture looks wrong and people are calling for a rewrite of the complete program!  Probably more important than how you try to mitigate against uncertainty with techniques like short-lived branches or prototyping is how you decide what to rewrite and what you decide to live with.  The problem to solve is deceptively simple – does the benefit of redoing a feature or rewriting an application outweigh the cost – but difficult to evaluate.  How do you measure intangible qualities like how maintainable and understandable your code is against the business value of features?  I wish I had a magic answer but the best I can offer is experience, which is unfortunately often gained by seeing when rewriting a feature or system wasn’t worth the cost.  One way to shortcut this learning is by studying the postmortems of other projects to learn from the experience of others.

Short-lived branches are an intriguing proposal.  No technique can completely prevent you from having code you wish was different and you’ll always have to evaluate the cost and benefit of doing rework, but short-lived branches might turn out to be a useful growth tool for developers who aren’t comfortable with ever throwing away any code under any circumstances, even when they know there’s a better approach that can be done within the budgeted time.

 

What do you think of short-lived branches? Start a conversation with me in the comments below.

Let's Talk