The Virtuous Traitor

I was just reading some articles and comment threads debating the issue of git merge verses git rebase. I think it's a good case study for a decision-making methodology of actually trying both sides. I think outside of software development, the cost of trying both sides of a debate can be high in terms of time, effort, and money. Let's say hypothetically there are several competing theories of long-term crop management for farmers. It would take many years, lots of technical know-how, and lots of dedication to split a large farm into portions, each serving as a guinea pig for a particular crop management technique. However, in software development, many of these techniques can easily be tried on some small/fast basis like a side project, a particular feature, etc.

For example, my web site has a mix of content and features that make it debatable as to whether a real dynamic application is warranted or would a static site generator approach suffice. I bypassed a lot of debate by just running it both ways for a meaningful amount of time, and at the end it was clear to me which way I preferred.

When you see some of these debates, for example:

• git vs mercurial
• merge vs rebase
• functional vs OO
• shell scripts vs configuration mgmt
• use DB constraints heavily or lightly
• language X vs language Y
• tool X vs tool Y
• Would I prefer consulting to full-time employment?

It's good to think about how much time and effort would it take to actually give each option an honest, non-trivial try. Often I find it's worth it and after the fact I have real first-hand knowledge to show for it. I'm particularly fond of first-hard knowledge/experience and skeptical of opinions held based on reading/hearing third-party opinions.

Here's a few recent things I put through this methodology:

• Is coffeescript worth using?
• Are docker containers interesting and useful?
• Is ansible better than my existing shell scripts?
• Would Atom be any better than Sublime?

Based on the cases made in the articles I was reading today, I plan to try a rebase-driven methodology on my next git project given I've mostly been doing merges and see how it goes.

Play for both teams. It's often the best way to guide a decision. And don't forget that after a while things change and sometimes we need to re-visit old preferences.