Going to PHPBenelux was a lot of fun. I will remember one of the questions at Ben Straub’s presentation. The question was “What if a maintainer of a project suddenly quits?”, and the answer was “We don’t have a technical solution to this social problem yet”. By now we’ve made our own technical solution to a social problem.

So what was your social problem?

We’ve been thinking about improving our deployment system. If you think about deployment in a abstract sense, you can make a nice triangle between the version that is deployed right now, the target version that you want to deploy and the latest version of the master.

The master branch in this scheme should always be able to go live. So if you’re deploying a version that is not merged into the master yet, the next person has a problem (he’s missing some commits). So now, before deploying, we compare the the target tag with the master, to see whether it’s been merged. That’s our technical solution to a social problem.

Should you avoid a technical solution to a social problem?

One side of the story, probably the one that makes sense, is that you should educate your users. It can be that you have to many users to educate, in that case this kind of artificial limitations makes sense. In this case this is not really valid, since there are only a limited amount of programmers using this tool. The reason why this was made is to enforce an invariant: All commits that are deployed to a live environment are always in the master branch.

One thing to take into account is that a user running into this kind of limitation will understand why he ran into it, and how he can perform the action that he wants to. So the user interface has to be clear as to why this limitation exists. Then I guess this technical solution to a technical problem is ok.

For those interested, the image was built with graphviz, see instructions at this github gist.