Quantifying the advantages of a modern version control system [closed]

Question

I've worked as a team lead/developer in a large financial enterprise environment for the better part of three years. Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it.

One of the first things I did when joining was to set my team up with Git. Everyone agreed that Clearcase was awful and was impractical for handling day-to-day source control matters. So we set up a sort of "unofficial" repository on my local machine and I wrote a script to sync our git and Clearcase repos around release time.

Word of this spread to other teams and several have adopted the same process. Using git in an "unofficial" manner for day-to-day activities and "officially" using Clearcase for releases. I've become sort of the go to guy for any issues with Git.

So I have a meeting this week with the SVP in change of infrastructure who specifically wants me to explain to her the merits of Git. Word apparently got to her of my frequent rants on Clearcase. If she accepts my arguments, I will have a real shot at helping my employer rid themselves of this abomination.

My experience with executives tells me they a) want extremely terse explanations for everything b) are only interested in facts that involve dollar figures

To a developer I can explain the merits of Git over Clearcase (or ANY other version control system over Clearcase for that matter), but I'm drawing a blank on how to do this to a technical executive without a technical background (she has an MBA and did her undergrad in geography).

I feel any argument I make to her is either going to sound like technical gibberish or that I'm evangelizing my personal preferences.

What I'm trying to find are concrete facts demonstrating developers work more effectively with Git, or ANY modern source control system.

I think that the fact the other teams have started using Git internally is a meaningful sign, but it's still not strong enough because it can still be dismissed as personal preference.

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

Answer 1

I've been in very similar situations (in the aerospace and automotive industries). Don't expect to progress very far in this or subsequent meetings. Both of these situations outlasted my desire to continue fighting for improvement, but here is the best tactic I've seen so far...

You say "this process has worked for 20 years", but has it really? Start by outlining what you mean by "our production release process is a nightmare". Create a list of issues with the current process/tool that is as agnostic of ClearCase as possible.

Then, create a list of process/tool "solutions" that are as agnostic of Git as possible (though Git or any modern DVCS will like fit the bill exactly). Explaining why Git is better than ClearCase means nothing to non-users.

Allow the infrastructure team to confirm that the current approach has the issues you identify. This will likely lead them to seek support from IBM to "fix" these issues. Remain connected to ensure IBM doesn't side step the issues. Because ClearCase lacks the basic properties of our modern understanding of version control, most of these issues can't be fixed or will require a major infrastructure change.

Hopefully by this point, the infrastructure team will see this as a business problem, but one without an easy solution. At this point, you offer to benchmark additional solutions with estimated costs. Since many of your teams are already using Git, you should be able to remove training as an expense.

Good luck!

Answer 2

Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it.

No, your process is a "nightmare" because of your change management group and your release procedures. Go ahead and replace Clearcase for SVN or git or Fossil. You'll have the exact same problems. (I think they're doing it right TBH, strong release controls are essential).

This is what you need to focus on, not the geeky credentials of git (which are irrelevant to all but the devs), you need to focus on the business case for changing the process to mae it less onerous. Chances are you can do that using Clearcase, but it gives you an opportunity to sneak the idea of using git in anyway.

If you don't look at the "bigger picture" here, the best case you'll get it to use git with the same restrictions the release group require. IF you do consider the wider aspects of what change control is for, then you'll appreciate the restrictions you'll have to implement to make git useful in the kind of strongly-controlled release process your org needs.

---

Some ideas for you: Get them to see the productivity issues with the current system from a developer point of view. Do this as part 1 of 2. Part 2, go and work with them on a release so you can see the control issues that you developers need to understand. Treat it as a learning exercise for both sides to view the other side's view, and then you should be better able to come up with a solution that still solves the major requirements either side has. Note that releases are more important than dev, so you should be the one prepared to give ground more than you expect them to.

Once you have the knowledge of what's required for releases, you should agree to write up a process document detailed (with steps-to-follow kind of detail) that you can show them giving them what they need. How you can massage this so the dev side is better for you is up to you. I imagine they don't really care how dev does dev, as long as the source is properly managed and releases correctly organised - that means you'll have to show how code changes can be tied to change tickets, how to take code that made a release to patch, build and re-release it.

Answer 3

Specific examples will impress more than abstract advantages. I think you will find most success if you can document particular examples where (a) Clearcase caused problems that took time to solve and (b) Git solves those problems. Remember that you don't need to go into technical details of why this is so (unless asked) simply show that it is; management doesn't need to know the technicalities, that's what you're paid for.

If you can attach specific timescales and dates to these examples so much the better. You might also be able to top this off by showing that task X that you do a lot takes Y minutes in Clearcase and Z minutes in Git.

Remember that time is money so if you can show that working with Git is quicker you can show that it will also make financial sense.

Answer 4

Here is an attempt at how I would try that.

That may sound stupid for a developer, but to management, technological changes are seen as risky.

"If the magic thingy already works, why take the risk to break it?"

Thus, you have to turn the table. Make it more risky not to make the switch to git. At all costs, don't make it sound like it's a new toy.

I would start by saying that git is now widely used. Use numbers, like those : http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

For a manager, this implies that they should be able to find plenty of developers using git. And a whole ecosystem of third party tools (I heard even Microsoft integrates git with visual studio now).

Also a manager can't really be blamed for following the mainstream things, do they? In contrast, who uses $other_cvs here?

Put emphasis on how large projects are using it, because it is simple, fast, flexible, powerful... Find big projects with big names attached to it (GNU/Linux, Google, Microsoft...) that use git.

Having demonstrated that it cannot be a bad move, you could then go on to how it would improve things in your case.

You want the company to stay competitive, and not be outrun by faster, more agile teams, right ? I would try to find some internal (written) estimations on how the productivity changed by using Clearcase vs Git. You could use some help from you fellow developers there. Then extrapolate for the whole company (ie. all software developers), with numbers and estimated cost of staying with Clearcase.

I would even if appropriate recap the whole thing in a written e-mail after the meeting (include the right persons).

Answer 5

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

This is an invalid argument (horse-drawn carriages have "worked for centuries", but you probably want to buy a car instead).

I have heard the same argument about svn vs. mercurial (I was the one using mercurial on my development system).

This problem is not about replacing what works; Don't try to phrase it as such, and if this is the question you need to "defeat", you should start by pointing out it is not a matter of what works or not - but a matter of what advantages you have with git, when both work (and why git works better).

Good arguments for using git:

• git is changeset centric instead of file centric. This means changes are easier to track accross files (trackability accross the project).

• git is distributed instead of centralized; This means checking in stuff isn't limited by network speed - saving a lot of time, again. It also means you have no single point of failure in case your ClearCase server goes down.

• because of it's branching system, git minimizes the need to merge (i.e. you do not merge files on every check-in, but but on every completed feature). You switch from solving merge conflicts (if any) a few times per day (on every commit) to once or twice per week (on every completed feature). This means more development time for your developers (something managers will want to maximize).

I think that the fact the other teams have started using Git internally is a meaningful sign, but it's still not strong enough because it can still be dismissed as personal preference.

You can point out that the qualitative difference is so big, that developers accross your company prefer the complications of installing, configuring and using git, on top of Clearcase, for it's extra features. It is actually a strong argument (if it didn't provide an alltogether better user experience and feature set, people wouldn't go the extra mile to use it - especially since it is something not required by the company).

So I have a meeting this week with the SVP in change of infrastructure who specifically wants me to explain to her the merits of Git.

Draw a chart representing commits with the two systems, and show the streamlining obtained by developers not comitting publicly (i.e. if you bork a file, the rest of the team is not blocked and unable to complile until you fix it). Also explain the extra quality controls you can make when you can make intermediary commits without affecting anyone else, the fact that you can get clean diffs per feature (essential for code reviews).

Answer 6

What I really need is something powerful enough to break through the "This process has worked for 20 years, why should we change it?" argument.

It's hard to really judge what would be a good argument without being a witness of the scene. But I'll try to help you frame your arguments so that they may be heard.

I assume your audience to have be a non-expert level of knowledge on the topic, and to have an interest in staying the current course. They have different concerns and responsibilities, and they may suffer serious consequences if something goes wrong, so you'll have to work from that mindset. Anticipate some of the questions or worries they might have:

• What new capabilities would this bring? Is there something that we currently cannot do, that we would like to do, and that this new thing would allow us to? Start on a positive note.

• What is the impact on release schedules? What is the cost of implementing this change towards the immediately next release? What are the costs and benefits to following releases?

• Will this entail a change in process? As distinct from the release schedule, will this change require that people in the release process change their ways? Will this be transparent to them, or will they need to adapt? Will you need to cooperate with other departments? People are resistant to change.

• Are there imminent dangers to sticking with the current system? Does the current process have software or hardware dependencies that have gone or will go end-of-life soon? Does it rely on specialised knowledge from individuals that drives up hiring costs? Does it have a potential security hole that the new system plugs (bonus points if this hole can lead to legal action)? Don't hand-wave or 'maybe' or 'probably' this: the sense is that it worked well for 20 years, so the burden of proof is on the advocate of change.

Also, be specific about problems and solutions. If you can't find specific examples, use honest estimates from your position as an expert. Examples of other companies/departments/entities adopting such a change, preferrably from your industry, and their evaluation of that change, will help you. (Don't pick examples that had some sort of publicised IT issue in recent years, or the onus will be on you to prove that this change was not the cause.)

You may find this answer to Convince the Company I Work for to Implement Version Control? helpful.