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.