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.

Is “fit for purpose” fit for purpose?

Channel 4 News’s Michael Crick issued an impassioned cri de coeur on Twitter last night:

I had to agree with him:

This led to an interesting discussion on Twitter, which got me thinking more about this increasingly ubiquitous expression.

“Fit for purpose” is a phrase that frequently gets bandied about in business circles, particularly in relation to technology contracts. Disgruntled buyers will protest that the software wasn’t “fit for purpose”, or that the hosted service they are using isn’t “fit for purpose”. And, as was pointed out in the discussion on Twitter, politicians are also fond of the phrase – ever since John Reid declared in 2006 that the Home Office wasn’t “fit for purpose”.

John Reid may have pushed the phrase out to a wider audience, but the explosion in popularity of “fit for purpose” had started some years before this, as this Google Ngram shows:

Google Ngram of 'fit for purpose'

As I said in my reply to Michael Crick, though, I’m not sure that people who use the phrase always have a clear understanding of what it means. Certainly it usually gets used in situations far removed from its original context in sale of goods law, in particular (today) s.14 Sale of Goods Act 1979.

The Sale of Goods Act describes two different ways in which goods can be “fit for purpose”. The first is as part of what it means for goods to be of “satisfactory quality”. This includes:

fitness for all the purposes for which goods of the kind in question are commonly supplied. (s.14(2B))

The second (and what is normally meant by “fitness for purpose” in the context of the sale of goods) is in s.14(3), which applies where the buyer makes known to the seller “any particular purpose for which the goods are being bought”. In that case:

there is an implied term that the goods supplied under the contract are reasonably fit for that purpose, whether or not that is a purpose for which such goods are commonly supplied.

So those are two fairly narrow and specific meanings. And before anyone runs away with the idea that these are just two statutory underlinings of a more general concept, s.14(1) slams the door firmly shut on this, at least as regards the sale of goods:

Except as provided by this section and section 15 below and subject to any other enactment, there is no implied term about the quality or fitness for any particular purpose of goods supplied under a contract of sale.

So the use of the phrase “fit for purpose” to describe services or software, let alone government departments, is some way removed from that original meaning – though, to be fair, it can also be seen that the wider use isn’t wholly at odds with the legal meaning.

But why is this a problem? Why shouldn’t people, in a business or technological context, use a phrase that has meaning for those in the discussion, even if it annoys legalistic pedants? There’s no reason at all why they shouldn’t – provided the pitfalls are recognised. In particular:

  1. “Fit for purpose” is often used in a rather imprecise sense and, like a lot of business jargon, may often be a symptom of imprecise thinking – which may come back to bite people later on.
  2. People who say “fit for purpose” often think they are talking in “legal” terms, which can cause confusion when the legal position turns out not to support them as they’d expected.

The biggest problem comes when the buyer ends up dissatisfied with what they’ve got out of an IT contract, and protests that the software or service wasn’t “fit for purpose” – only for the seller to point out that they’ve complied with what the contract actually said they’d do, even if this turns out not to be what the buyer wanted; perhaps because the buyer thought they’d be able to rely on some general principle of “it has to be ‘fit for purpose'”.

In any event, whether lawyers (or Michael Crick) like it or not, “fit for purpose” is here to stay. How should commercial lawyers handle this phrase? The best thing is to find out what our client’s “purpose” is, what “fitness” for that purpose looks like, and then put that into the contract – rather than the vague phrase itself.

Though I hope we can be forgiven for occasionally wanting to let off steam on Twitter about it, too. 😉