I mean, seriously, isn’t this just version control?  Haven’t we solved this problem a million times with Subversion, Mercurial, Git and so on?  Why is this such a big deal?  Take the latest version of the content, merge it in.  If there’s concurrent modification then identify a conflict and kick it up to the user to resolve.  Done.  Look, they even came up with a standard, SyncML, on order to normalize communication of sync information.

And yet still, in 2008, I’m sitting here on the verge of starting with a new employer, and I’m wondering about what I’m going to do about their Exchange server.  Do I go for a Mac and use Entourage?  Try to push everything into Google calendar?  Use Spanning Sync to connect up iCal?  These are a lot of acrobatics – why can’t this Just Work?

Just to demonstrate that I’m not completely talking out of a nether-oriented-orifice, I’ve even started to do some work to lend sync services to Django.  It should be no surprise that I’m letting Mercurial do the heavy lifting.

Why is this space so backwards?  Well, I’m tempted to blame Microsoft – they managed to get the whole world to buy in on Exchange.  Companies that made otherwise sane technology decisions went with classic vendor lock-in, probably because there wasn’t much else out there to compete at the time.  Microsoft (man, it feels tired just talking about this) plays well with other Microsoft products, but not well with others.  There’s no CalDAV connector for Exchange, for example, meaning there’s no standards-based access to their calendar.  Grr.

Another reason this space is so lame is because sync has been too long considered to be an application feature, rather than a service (perhaps an OS service?) available to be leveraged by various programs.  This is the approach now taken by OS X, so I guess there’s some hope.  Even in the relatively advanced world of OS X, there’s a lot of hacks still going on.  I’m currently sync’ing OmniFocus on my desktop with the OmniFocus on my iPhone, using a WebDAV server that I set up myself.  NetNewsWire syncs by using NewsGator.

Dodgy.  I mean, this sort of works, but people don’t go around rolling their own disk i/o or network stacks just because their applications use them.  This stuff should just be available to use.  And it should Just Work.

UPDATE:  Ironically, Google calendar announced CalDAV support today.

In system design, be it a network, application or any other piece of automated infrastructure, we eschew single points of failure.  We know that in the real world, things go wrong, and consequently we design systems that have redundancy built in.  If something fails, the system can transfer operations over to a redundant subsystem, and keep on going.  That’s why, for example, websites have back-up load balancers or data servers.  These apparently redundant elements are there to keep the system online if the primary subsystem breaks.

Unfortunately, in the I.T. world, it is common to neglect that the human operators of automated systems are also effectively part of that system.  They can also constitute a single point of failure, and we should be avoiding this problem with humans as well as machines, for the same reasons.

No single operator (be they employee or principal) should ever control exclusive passwords or knowledge about a critical system. To do so makes the system fragile, and sets it up for the kind of snafus that are currently plaguing San Francisco.

In the linked article, it’s described how the network administrator in question was unwilling to allow anyone else to work with the network because he felt they were incompetent, and the configuration for the network was extremely complicated.  I can’t help thinking that centralizing control over the network was a band-aid on a tumor, however.  Essentially the city was running a network that was too complicated for them to staff properly, and was relying on a bad management decision in order to cover for it.

Essentially this is trading risk for cost.  However, it raises the question about whether it was acceptable risk and whether the decision was made consciously, or if it just happened through the ignorance of the network administrator’s supervisors.  I’m betting the latter.   This was sweeping the problem under the carpet, and the city of San Francisco is now paying the cost.  Bad policy.