I’ll kick off this topic with a little anecdote.
I still remember clearly how one of my former bosses’ responded with “that’s bull****”, in the nicest, non-blaming way possible, when I told him that one of the feature branches I was working on didn’t get merged into the trunk because of 1 tiny bug.
So the whole story went something like this:
- A new feature on an existing product was decided to be valuable
- A feature branch was created to make this happen, it was allowed approximately 6 weeks to delivery
- I was the sole developer on this
- Some other project I had ownership on needed some significant work as a priority half way that through developing this new feature
- No one else could take over the task for this new feature because no one knew the progress on it
- I came back to it, master branch was significantly changed by then, so I spent a good day trying to remember my progress and sorting out a massive merge conflict to merge master into the feature branch (to avoid a even bigger one when the other way around needs to happen)
- When it was ‘done’, it was passed onto testing. Significant amount of time was spent on going back and forth fixing bugs.
- And then there was this one minor bug that blocked the entire feature branch from being merged into master — hence stopping the feature being released
- Before I knew it, 5 months had gone past
Absolutely not ideal for anybody. Not for developers because motivation is lost after about 2 weeks (I definitely lost mine there); not for testers because they’ll have to test the whole thing once it’s done; not for users because they don’t have a clue what’s coming and they’re not even sure if it’s something useful; and definitely not for the company, because it’s high risk. This was probably one of the biggest mistakes I had made in the past and definitely don’t recommend anyone to try this at home.
Now I have contemplated for a few more years, I hope I have gathered a bit more experience to prevent that from happening again, so here’s some things I want to share.
- Products are valuable only when proven to be
- Feature branch is bad
Products are valuable only when proven to be
It doesn’t matter whether you are making a space shuttle or a cardboard box, if it doesn’t serve any purpose to anyone, it is not valuable and there is no point in making it.
In other words, if you want to find out whether your feature is useful, you need to start speaking to potential customers. The most cost-efficient, risk-free way is not to make a complete feature, throw it out there and see if your product is being used.
If your feature is not useful, you’ve wasted all your time making it. And it’s probably not lean enough for you to easily make changes to it because you’ve been so focused on what you initially thought would be useful.
The trick is to have small feedback loops.
It means, if you have an idea that you think is valuable, making small changes to your existing solution, let your users know that it’s a beta feature, start getting feedback from them on what problems they’re trying to solve using your feature, how do they hope to see this feature working etc. Get users to guide your product to an end product. In the end of the day, you are creating a solution to resolve their problems. And they know best what their problems are.
The longer you keep your customers in the dark on what you are making, the longer you are keeping yourself in the dark on what the customers really want.
Feature branch is bad
It flows naturally on to why feature branch would not be suitable for achieving small customer feedback loops. In short, if you have a feature branch that lives for the duration of your new feature, it naturally means you won’t be releasing this feature until it is done and tested.
Apart from its incompatibility with small customer feedback loop, anecdote tells, if you have a feature branch, only the people working on the feature will be in the loop on its progress. While it’s nice and comfortable to keep your feature development in isolation, if for whatever reason other developers need to start working on this feature (it is not uncommon), it will take them much longer to get on board.
Moreover, if you have a product manager, development manager, sales team, marketing team and a testing team all waiting on this feature, you’re keeping them all in the dark. Because most likely, most of the parties will only care about the product version that’s already out there/what’s on the master branch.
On the contrary, trunk based development is much leaner. It can adapt to changes very quickly. That is both in terms of requirement changes and adding/removing people working on it. Also testers can test small changes, as opposed to one big feature on the whole and identify a bunch of bugs all in one go at the end.
Thierry de Pauw’s talk on “Feature branching is evil” also explains other benefits of trunk based development over feature branching.
To be not so biased, there are some difficulties. The biggest difficulty I had faced when I first started adopting this methodology is on how to break up a big task into much smaller, digestible ones. Since the master branch needs to be in working condition at all times, you cannot just commit half done code into it.
In short, the trick is to start off with implementing an ability to hide your work in progress code, to make it only accessible in development environment. Thereafter, whatever you write, you just need to make sure it compiles.
In conclusion, having small external feedback loops from customers reduces risk on the company; having small internal feedback loops allows a more maintainable common ground between development team and other involved parties. While it can be difficult at times, it is also achievable and can become natural if you force yourself to only create short lived branches.