Closer To The Ideal

Git handles merges better than Subversion:

Subversion has worked for us up until now on the project, but it is falling short of meeting our process and productivity needs. Without effective merging, branches won’t be used no matter how cheap they are to create. The only Subversion branches we have ever created have rarely stayed in sync with upstream and always led to dramatic merging ceremonies, worries about regression and code loss. To make a long story short, Subversion supports parallel development, but makes it so difficult to use effectively that you are better off avoiding it altogether.

Git handles our roughly 500,000-line Enterprise Java code base with ease. It is faster for one developer to git svn clone and then have his peers git clone than it is for each developer to checkout simultaneously from Subversion. Once done it gives every developer on the team offline access to the entire project history. The offline access allows developers to do complex historical comparisons that would be slow enough in Subversion to discourage developers from doing them. Git not only makes certain reporting operations fast, it makes them practical and productive to use.

I haven’t yet used git. I’m still making up my mind about whether I feel any need to move beyond Subversion. I am collecting quotes about git, both for and against. To this end, I found Jacques Distler’s offhand remark interesting:

One really annoying feature of Git is that it ignores empty directories in commits. Why do people put up with that? There are a bunch of such directories in Instiki (and, indeed, in most Rails apps), so Git seems particularly ill-suited as a source repository for such projects.

There are several good posts over at David N. Welton’s blog, and I’m going to post short excerpts here.

Welton is one of the two people working on hecl:

Hecl is intended as a complement to the Java programming language, not a replacement. As such, it tries to do well what Java doesn’t, and leaves those tasks to Java for which it is best suited. Hecl aims to be a very immediate language – you can pick it up and start doing useful things with it quickly. It is also meant to be easy to learn. Where Java is verbose and rigid, Hecl is forgiving and quick to write. For instance, System.out.println("Hello World"); vs puts "Hello World" – 41 keystrokes (shifted letters count double) versus 22. Hecl is built to “scale down”.

This makes Hecl ideal for large applications written in Java that would like to provide a user friendly scripting interface, rather than, say, a clunky XML based configuration system. Examples include: scripted web pages, command/control logic in long running applications, and, I’m sure, many environments I’ve never considered.

hecl strikes me as arising from the same economic/technological forces that have in recent years lead to the explosion of script languages running on the JVM: JRuby, Groovy, JavaFX, etc. hecl doesn’t necessarily run on the JVM, but, as I say, its existence seems due to the same underlying trend – the reality that for many projects it is economically rational to trade away program execution speed in exchange for greater programmer productivity.

The mobile phone is a good environment for Java and yet hecl might work even better in this environment (in that sense, it might be a direct competitor of JavaFX). They’ve apparently gotten a prototype working:

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs!

Welton also writes the only article I’ve ever read that says something negative about git:

The whole thing seems kind of shaky in the sense that it’s not very confidence inspiring: I feel like it wouldn’t take much to make a wrong turn and find all my files gone forever. I can see some of the advantages, and will likely stick with it – git is quite convenient for local files that I might not have bothered putting under version control in the past, but it’s also a bit more “bureaucratic” in that you have more steps to do, and you have to fill in the forms just so… or else!

And this is the only negative thing I’ve ever read about github:

However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who ‘owns’ the project, rather than existing on their own. There are a few exceptions – there seems to be a ‘rails’ role account to manage Rails, rather than having it belong to, say, DHH, so it’s not impossible to do something in a project-centric fashion, but it doesn’t seem to be very common either.

What I’m wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to ‘fork’ projects. Could, or will this lead to a situation where people don’t try so hard to get their code in the ‘official’ branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they’re not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the ‘dead’ branch, or simply be confused as to who’s doing what. This could make things confusing for someone who just wants to check out some code and start using it…. trying to sort out various revisions and ancestry of a project could be quite discouraging.

Finally, Welton thinks of Coase and his Theory of the Firm when considering how smaller transaction costs in certain industries might be leading to more freelance gigs and less permanent jobs:

So if one wanted to look, in a less anecdotal way and slightly more scientific way, about whether the US, or other countries, are turning into “gig economies”, one could do worse than look at the transaction costs associated with utilizing contractors as opposed to permanent employees. If those costs have fallen (it may be easier to find people, thanks to the internet, for example), perhaps it is more efficient to have more contractors and fewer full time employees and so the equilibrium will tilt in that direction. Of course, another explanation might simply be that the economy is bad, and companies don’t have the budget to take on more people, so they get by with what they can in the short term.

For me, this is one of the main ideas I took away from the work of H. T Goranson. During the 1980s Japanese manufacturing firms used their focus on quality to beat American manufacturing firms. By the early 90s American companies were trying to catch up with the Japanese innovations in quality. Many American economists and business analysts worried that the next great zone of innovation would be agility. Organizations such as DARPA were sufficiently worried that they gave out a lot of grants to people like Goranson. His work concluded that, at least in the American context, small firms were uniquely innovative, but their innovations would be at least partially wasted if they could not be brought into the supply chains of the largest manufacturing firms. In this context, agility was defined as the ability to overcome the transaction costs associated with dealings outside of a firm. A truly agile supply chain would be one where numerous small suppliers could be quickly brought together into a completely new supply chain, with little additional cost (that is, the annoyance of dealing with lots of small firms would somehow be minimized). The model was Hollywood, which, in just a few weeks, is able to pull together a vast and diverse group of professionals to create a new movie. Goranson looked at everything from legal traditions to social mores to technological innovations that contribute to agility.

Needless to say, that kind of agility has become an increasingly important part of the economy, and possibly has become a unique competitive advantage of America.