Schofield’s Laws of Computing: your cut-out-and-keep guide

Jack Schofield (and Pipe), by Aleks Krotoski

Photo by Aleks Krotoski.

The Guardian’s computer editor, Jack Schofield, has formulated three “laws of computing” over the years.

I’ve found these useful to keep in mind, both in my own personal use of computers and in advising on IT contracts, so here is a quick post bringing all three together in one short list:

  • Schofield’s First Law: never put data into a program unless you can see exactly how to get it out.
  • Schofield’s Second Law: data doesn’t really exist unless you have at least two copies of it.
  • Schofield’s Third Law: the easier it is for you to access your data, the easier it is for someone else to access your data.

Of those, I’d say the first is the most useful in a commercial IT context. (This post was prompted by reviewing a contract in which our ability to do this isn’t as set out as clearly as I’d like, though I’m sure it’s not going to be a problem in practice.)

In my personal IT use, it’s the second law that is the one I always keep in mind – and that I try to find a gentle way of pointing out to people when they are mourning the loss of family photographs in a hard drive crash or laptop theft. Dropbox is your friend, people! 

The third law is both vaguer and probably of wider application – particularly after the Year of Snowden has highlighted how porous supposedly “secure” IT systems can be.


“Pretty” is a feature for contracts, too

An ugly suspension bridge, yesterdayCame across the following quotation from Eric S. Raymond, the godfather of the open source development model, in an article he wrote about the programming language Python:

Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity.

That makes a lot of sense to me, because I think the same thing is true of contracts. Ugly, badly-written, poorly-structured contracts seem far more likely to “collapse” (into uncertainty, failure, disputes and litigation) than contracts that are well put together.

This isn’t because getting your paragraph numbers aligned is guaranteed to prevent a contractual dispute. It’s perfectly possible to have a contract that is beautifully laid out, but legally and commercially inadequate. However, in practice there tends to be a correlation between the visual appearance of a contract and the care with which its content has been drafted and negotiated.

Eric Raymond gives a deeper reason for this: it’s because contracts can be complex things, and a large part of how humans process complexity is through our ability to grasp structures and patterns, both visual and conceptual.

Or, as another well-known figure in free/open source software, Mark Shuttleworth, put it:

“Pretty” is a feature.

This is just one way in which programming and legal drafting have many similarities (this post by @grabbeh gives some more). This shouldn’t surprise us: both are concerned with using language (often rather esoteric language, even in these days of “plain English” drafting) in precise, logical, well-designed ways to achieve an outcome in the real world.