In the ideal world a technology will be selected on its own merits alone. But we don’t live in an ideal world, and every technology has to work in a specific situation. So sometimes choosing a technology because lots of other people did, too, isn’t such a bad idea.
Some time ago I worked with a team that was considering moving their source control from TFS to git. (TFS wasn’t being used for anything else; just source control.) The initial reasons were around licensing and consistency with other teams (whose work we rarely shared, anyway). But the move would be a wrench, and it would be notably more difficult to use, if only because within that organisation internal support tools had been built up over the years around TFS.
In the process of deciding I needed consider this: when listing the reasons to move to git, how much of a justification is “because it’s modern” or “because it’s popular”?
I think it depends how you want to place your bets on your future. No-one knows the future, so you can only make a bet. If you’re sure your future will be very much like your present, then it’s not worthwhile. But if you’re not sure about the future then something that has a bigger userbase for people in your position is a good bet. That’s not just for support reasons, but because there will be more opportunities created for migration paths if it’s a bad bet. Those opportunities may be created by those in that position or by people who have the next new technology to sell.
I was reminded of this while watching Stefan Tilkov relate some architecture war stories. There were many technical lessons to be learned from his stories, but it was notable how many lessons related to business and to people. To make these decisions effectively you sometimes need to understand the technology enough to be confident to look past it. I’ve said previously that your architecture impacts your business strategy; similarly, your business situation must impact your architecture.
niksilver.com 