jims musings

The oil cometh.
Again, I note that despite the vol­ume of oil lost over the last 30-someodd days, the world still awaits pho­tos of ter­ri­ble envi­ron­men­tal destruc­tions.
Again, Politi­cians, tone down the rhetoric. Yes, this is a ter­ri­ble spill. Yes, the poten­tial of large, expen­sive prob­lems cer­tainly looms. How­ever, blam­ing ‘greedy’ cor­po­ra­tions and shut­ting down oil drilling is not a solu­tion nor a good reac­tion. We don’t cease air­line flights or dri­ving when a crash occurs.
A quick review of the mag­ni­tude of the prob­lem– the largest in U.S. his­tory:
The high esti­mate is 19,000 bar­rels per day. (At cur­rent oil prices, that’s nearly 1.5 mil­lion dol­lars lost per day.)
19,000 barrels/day X 42 gallons/barrel X 1 day/ 86,400 sec­onds
= 9.2 gal­lons per sec­ond, or 554 gal­lons a minute.

This is about the same flow rate as a 3-inch fire­hose is capa­ble of. Men­tally then, think of that– a fire­hose of oil, run­ning a mile below the surface.

The busi­ness of soft­ware devel­op­ment is comic. You’d expect that the peo­ple who make com­put­ers do all that whiz-bang stuff would have awe­some star-trek-like tools at their fin­ger­tips.
Nope.
Here, now, in the Twenty-First Cen­tury, soft­ware devel­op­ment is still done in plain text. Peo­ple, under­stand: a Word or Excel doc­u­ment is an incred­i­bly sophis­ti­cated chunk of tech­nol­ogy. Soft­ware code is just… text. Noth­ing else. Office doc­u­ments have Revi­sion con­trol, secu­rity, stored undo infor­ma­tion and all man­ner of stuff. Com­puter code is just… text.
How­ever, devel­op­ers have an awe­some tool in their arse­nal: Source Code Con­trol. Sim­ply, this is a pro­gram which man­ages all the text files which are used to cre­ate a com­puter pro­gram. All the files for cre­at­ing a spe­cific pro­gram are known as a project. Source Code Con­trol allows many peo­ple to work on the same files at the same time– it fig­ures out how to merge all the changes together. Not only that, it allows devel­op­ers to move back­wards in time, or it allows the cre­ation and merg­ing of copies (branches) of the code. It’s very handy, and I’m sur­prised that large offices have never picked up on this. Most of the time, doc­u­ments are strewn about on peo­ples com­put­ers or the office network.

The point of this dis­cus­sion is a rel­a­tively new direc­tion in Source Code Con­trol, known as Dis­trib­uted Ver­sion Con­trol. This intro­duces a sub­tle but very awe­some capa­bil­ity: you no longer need to be con­stantly con­nected to the cen­tral source to com­mit changes. I could be in a sub­ma­rine, com­pletely cut off from the world, but still have all the advan­tages of com­mits, roll­backs and his­tory on my lap­top. When I do get back in touch, my changes auto­mat­i­cally get merged with every­thing else. This is pos­si­ble because these new Dis­trib­uted Ver­sion Con­trol sys­tems track my changes instead of my ver­sions.
I’m excited about this because of a pet peeve: sav­ing files. Why do we save files? Why does google docs (or Word, Excel, etc.) have a pic­ture of a square thing that we click on to per­sist the changes we’ve made? (It’s a floppy disc, which I haven’t seen in real life for a decade. My chil­dren are more likely to see a mam­moth in their life­time than a phys­i­cal floppy disc.)
What I think is going to hap­pen is this: the con­cept of ‘sav­ing’ is going to fade away. Every key­stroke will be imme­di­ately saved away– after all, these are merely changes to a blank doc­u­ment. Office doc­u­ments, spread­sheets, com­puter code, pho­tographs, movies– all will be saved. Per­ma­nently. This will have tremen­dous long-term con­se­quences on data stor­age and pri­vacy, which we will need to con­sider.
The days of ‘the power went out and I lost my work’ are going away.