Lowering the barriers to Entry

or ... From svn to hg and back again (and more importantly ... where next?)

I have been using Mercurial for the past 6 months or so, and I am still only partially sold on the whole DVCS movement.

I used Subversion exclusively for around 4 years, between 2007 and 2011, and a mixture of Perforce, StarTeam & SourceSafe (shudder) in the years prior to that. (I even did it manually for a while, before I knew better). These formative experiences occurred (mostly) in corporate environments, where I was frequently faced with the task of evangelizing software development best-practices in teams dominated by non-programmers (academics or other domain specialists).

Here the challenge is in working effectively with colleagues who are accustomed to working alone for long periods, and for whom sharing of work is done through network folders and email (or peer-reviewed, published articles!).

It is easy to forget that most professionals will require a significant amount of convincing before they will tolerate even minor inconveniences. Subversion, one of the easiest version control systems to use, still presents major barriers to adoption. Mercurial, for all of it's DVCS goodness, requires yet more knowledge & presents yet more friction to the non-developer user than Subversion. I am not even going to think about discussing Git.

So, how can we lower the barriers to entry and reduce everyday friction for modern development automation systems? Can we make using distributed version control easier that using Subversion? Easier than using email to share work? Easier than using network folders?

Can we find a much simpler way to solve the same essential problem that version control systems, configuration management systems & source document repositories solve

Well, what is the essential problem that they are trying to solve, anyway? It has something to do with collaboration, something to do with man-management, and something to do with asset management, organization and control.

Like most issues that appear, on the surface, to be purely technological, when you peel back the surface, it becomes possible to discern psychological, sociological and political factors at play; but by the same token, once analyzed, these (potentially confounding) influences simply become additional technical problems that can be managed by technical means.

So, we use version control & configuration management systems is to help organize our source documents, organize our development processes, and organize how work is divided up and merged back together again. They give us visibility, they keep a record of what happened in the past, and enable us to predict and plan what is going to happen in the future. They are the ally of the obsessive-compulsive side of our personality, and they give us the comforting feeling that everything is under control. As much as they are anything else, they are also an emotional crutch, and in that, they are a political ally against the local-optimum seeking risk minimizers in life.

I have a lot of hope that real-time collaborative editing (Etherpad - Realie) and online development environments (Koding - CodeNow) will find success and provide us with a rich set of options for our future development environments; they certainly offer an aggressive simplification and improvement over the current state of affairs! (Although I believe that they will need to address the above political concerns to gain widespread traction in a conservative (small c) world.)

I also hope that these environments pick up the user-interface ideas that are being promoted by LightTable et al, and provide support for the broader engineering community (Embedded and safety-critical systems in particular) as well as web & enterprise development.