In the initial days, when I was trying to bootstrap the FreeCharge tech team, my team members were always trying to make me move us away from svn to git. For the past couple of years, if you have not been living in a cave somewhere without a net connection, you for sure know that git cures cancer(sic, sic). My team members, being the hacker news reading kick ass engineers they are, wanted to be part of the latest fad in version control system. Whenever someone used to suggest that we move away from svn to git, my first question used to be, what problem are you currently facing with svn? The answer usually used to be zilch, nada. In some cases where they pointed out issues, it used to be that they did not know how to use svn properly to achieve what they were trying to accomplish. Instead of investing few minutes in trying to figure out how to get better at the tool that is already part of the infrastructure, they wanted to disrupt the whole process and be part of the latest fad in the tech world.
I am sure anyone who has been part of the tech culture has witnessed this phenomenon. There is nothing inherently bad about using/wanting to use the latest/newest tool/language/framework. In fact, it should be encouraged, it is a clear sign that your team is not happy with the status quo, they wants new challenges, they are ready to come out of the comfort zone and tread into new uncharted territories. But, as usual, it is not as black and white as we want it to be.
If you are starting from scratch, it makes some sense to go with the latest, because anything that is new is a product of someone’s frustration with the existing and trying to better it. Someone writing something new has the advantage that they can learn from the experience of current, better all the issues that they faced with the current and not repeat the same mistakes that the current did. But, at the same time, there is a flip side to it, an existing product usually has a strong community behind it, the product has matured through various iterations and solved all the warts that would have been there when it was the new kid on the block. So, when using an incumbent, you are standing on the shoulders of giants and taking advantage of the huge community behind it. On the other hand, something new has the advantage that they can be scrappy, respond to changes faster than an incumbent, the community in the initial days is very enthusiastic to hold your hand because they want their product to proliferate. So, choosing over an incumbent versus new is more of an art than science, there are no hard and fast rules here.
Coming back to the git versus svn story, if we were starting our product from scratch, I would have for sure gone with git, but we were working on an existing product where svn was deeply entrenched in the eco system. Moving to git just for the sake of being part of the latest wave would mean significant disruption in our whole process and a considerable investment of time. Along with this, there was the question of educating the team members on git who did not know about the git works flows etc. It boiled down to the eternal question of do we spend time in doing this just to satisfy our geek curiosity or can we spend that same time in trying to fix some real issues that we had with our code/infrastructure. I leaned in on the latter.
Fast forward to today, we have moved to git. Our team was growing, branching and merging were becoming issues due to the way svn branches work. We were facing a real problem which a better tool would alleviate. It was no longer a question of being part of the latest fad but was about making ourselves more efficient as a team and we took the plunge. As a leader of a tech team, you will always be in this situation, do not blindly start using something because it is new and shiny, adopt the new kid on the block only if it solves a real problem. Any sort of change is always disruptive irrespective of how small it is, do it only if it makes your team faster and meaner and adds value to your product. I keep reminding myself this all the time, your customers do not give a shit as to whether your product uses cobol or node.js behind the scene, all they care about is how it adds value to their life. Being nose deep in the tech community sometime makes us oblivious to this fact.
Abhirama's Blog 