Antifragility and git flow

Antifragility is a concept coined by author Nassim Nicholas Taleb to describe things that benefit from randomness, chaos, or disorder. As things get weird, or sometimes even go wrong, antifragile things get stronger. Human DNA is antifragile, as is learning to ride a bike (and falling off). An expensive vase and a helicopter parent are not.

Today we had a debate about our development model at work. We use a model that’s fairly similar to Trunk Based Development, but we aren’t doing it perfectly. We had an issue arise last week, where one developer made changes to a javascript file on one feature branch, and another made changes to a HTML file on another branch. In both their respective branches, the changes worked fine — they passed automated testing, code review, and QA testing.

However, when both of these changes had been merged to master (or “trunk”), they broke. Turns out they both related to the same feature, and the two developers didn’t know about each other working on them. And it turns out they were written incompatibly.

One developer suggested we move to a model with a pre-release trunk and then designated release points. Unknowingly, he had proposed git flow.

We used to use git flow. It would be great if you were making software with a version number, but for a web app it didn’t suit us. The main thing we didn’t like about it was that we couldn’t do more than one release per week. But there are many things that shouldn’t wait a week to be deployed:

• Bug fixes
• New a/b tests
• Tweaks to wording

So we moved over to GitHub Flow. (We used the original version. The current guide suggests you deploy before a master merge, which I find confusing, and which we don’t do.) In my opinion it’s been much better. But if you are thinking of it in terms of just preventing all bugs, the benefits aren’t as clear cut.

Antifragility at its core is about having known downside, and unknown (but possibly very high) upside. In my opinion, that describes the model on the right. Sure, it’s possible that we’ll have conflicts from unrelated merges. But it’s not likely, and there’s things we can do to mitigate it:

• Ensure developers know what other developers are working on so they can pre-empt clashes
• Encourage developers to merge master into their branch before merging to master
• Force them to do this through Github
• Make our CI suite run faster to make all this easier

If we do any of these things we are learning and improving from disorder. Even if we do none of these things, and the occasional issue slips through, we can deploy a fix within a matter of hours. So the downside is fixed. Whereas the upside scales as well as our team does — the more features we can write, test, and merge, the more we can deploy.

Next time you have to make a technical decision, and there are reasonable pros and cons to every option, instead ask yourself what the upside and downside to each model are. And then ask yourself, which is more antifragile?