I was wondering how safe is to say that —because developers are free to version and have better and more organic workflows— code will be delivered faster.

A big factor here is team size of course, and I'd say the team is big enough to see this benefit (10-15 core devs, and maybe 5 to 15 more contributors to the common codebase).

Edit: How development speed can be affected:

  • Merging hell could be one of the cases that slow down people (DVCSs are much better at merging).
  • Better workflows that can pretty much only work work more naturally on a DVCS

    Integration Manager

    Integration Manager

    Dictator & Lieutenants

    enter image description here

  • Ability to use version control (i.e. committing) without inflicting potentially unstable changes to everybody

I just want to know if anyone has seen such things help the overall speed of teams/projects as a whole.

  • Why would code be delivered slower if you stayed with the CVCS?
    – user1249
    Commented Apr 22, 2012 at 7:09
  • @ThorbjørnRavnAndersen See edit Commented Apr 22, 2012 at 7:33
  • 1
    Have you researched if any of these "could slow downs" actually do?
    – user1249
    Commented Apr 22, 2012 at 7:50
  • 1
    @ThorbjørnRavnAndersen ...actually yes. Resolving difficult merges (which otherwise are better handled by DVCS's thanks to more robust version metadata) can take days because people don't want to merge and then someone has to, merging occurs way more often in DVCSs. Better workflows such as the ones presented shield non-interested parties from instability where they don't care for certain changes until they are stable (see Dictator & Lieutenants). Ability to use version control alone helps you refine your work faster. Commented Apr 22, 2012 at 9:15
  • 2
    Better workflows that can pretty much only work on a DVCS and otherwise be difficult on CVCSs I highly doubt that. At work, we use ClearCase and I set up a workflow very similar to the Separate features workflow often used with Mercurial. I've also been able to employ Mercurial's Sharing Changes workflow. I can see how you can fairly easily implement these in Subversion, as well. So I don't consider this a valid point of comparison between distributed and centralized versioning.
    – Thomas Owens
    Commented Apr 22, 2012 at 18:23

4 Answers 4


In our line of work, it's sometimes difficult to see the human element. I believe DVCS has the potential to speed up a workflow, but a large number of developers are either unable or unwilling to learn it well enough to use it to its full potential.

In my experience, around 1 in 10 developers already get it, another 2 in 10 would learn and use it to potential after the company switched, and when you explain the benefits of DVCS to the other 70%, they respond something like, "Why would anyone ever want to do that?" If forced to use it, they will make the experience as close to their familiar CVCS workflow as possible, thereby negating most of the benefits.

  • Good point, this is how a DVCS could slow things down. I plan to start a pilot test, and then try to expand it to the team that lies in another office for the same project, and see if it catches on. I'm hoping that with a good organic adoption roadmap and friendly and well-defined documentation for workflows will help avert this Commented Apr 22, 2012 at 19:28

If your CVCS is slowing you down (would be he corollary from your question) then your workflow is broken not your VCS.

Edit: (text to long for comment)

I think you are missing the point. If your procedures regarding VCS's can slow you down only if they make up a significant amount of your development time. This would be true if either the VCS or your process requires a huge amount of ceremony. I have never used perforce so I don't know how "bad" its ceremony is. I have used MKS and found its ceremony really bad, but it would still only account for a couple of minutes per day. With git my ceremony is maybe a couple of seconds a day. So my gain is less pain, but not much more speed, because if my day is 8h long it does not really matter if I save 10 minutes.

BUT: The pain is much (very much) smaller than with MKS and git makes things possible I could not do before. That is the real gain of DVCS.

  • 3
    But, conversely, wouldn't a DVCS that allows better workflows help increase speed? Commented Apr 22, 2012 at 7:42
  • 4
    DVCS's are not magic bullets or pixie dust. If you have social or political problems, no amount of technical solutions will help.
    – user1249
    Commented Apr 22, 2012 at 10:00
  • 2
    @EricSchaefer: "If your 486 DX with 256 MB of RAM is slowing you down, then your workflow is broken, not your workstation".
    – user988052
    Commented Apr 22, 2012 at 16:00
  • 4
    Can't really agree. We were in a situation where our (C)VCS system's lack of useable branching and merging was causing severe bottlenecks when we were trying to stabilise code for a release (while trying not to just tell all the coders to "stop checking in code"). I'm not sure any amount of clever workflow could have given us the ability to separate "stabilising" from "continued development" that switching to Mercurial gave us.
    – Arjailer
    Commented Apr 22, 2012 at 18:52
  • 2
    @ThorbjørnRavnAndersen I'm not saying that, but technical solutions can indeed solve social or political problems. Remember forking a project used to have a bad connotation for open source projects?, see what happened after github (a technical solution) eaves.ca/2011/06/14/how-github-saved-opensource Commented Apr 22, 2012 at 19:26

Yes. In day to day coding, there is not much of a difference time-wise whether you use one or other source control.

As for the learning curve of a new methodology in a group: the larger the group the steeper the curve.


This really depends on your development processes, build process, release management, and branch management. You need to pick the best VCS to support these without worrying about if it's centralized or distributed. The VCS should support your processes and you should not have to mold your processes to the VCS (within reason).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.