?

Log in

beer

Essential Difficulty

In Lawrence Lessig's book "Code" a major topic is the need to decide about things that have never needed to be decided before, they could be taken for granted. The book is a study of changes that have been prompted by computing and the internet. These changes in many parts come down to things that were not possible or were expensive before are possible and cheap. This has caused a need to re-evaluate what is legal/illegal, right/wrong, possible/impossible. It seems innocuous enough, but it has major ramifications. The law can no longer assume that something will still be done (on the internet) because there isn't somebody saying that it can't. That doesn't work anymore. Now you need someone explicitly saying that it *can* be done.

Why? Well because only what we make possible is possible inside these logical constructs we call computers. The system will do anything but will only do what you tell it to. So if you never tell a system to log that a user has logged on, you'll never have a record that a user logged on.

Fredrick Brooks talked about essential versus accidental difficulty in software development in his essay "No Silver Bullet." He credits the terms and the ideas to Aristotle. An essential property of an object is one which cannot be removed without removing some part of the identity of the object. An accidental property is one which does not need to be there but is for some reason or another. An accident property can be removed with no change to the object.

In "Code" the computers removed many accidental difficulties in law. An example would be copyright law never dealing too much with what exactly constitutes "Fair Use" because the technology at the time made it difficult to copy without limits. Computers removed the accidental difficulty of copying and forced us to deal with the essential difficulting of intellectual property ownership.

Today I was thinking about other essential versus accidental difficulties. One thing that came up often in my work was getting people to think about requirements in a system for logging. The problem here is that in most people's every day lives they have no need to think about such things. Common objects do not need to record explicitly what they did and what happened to them. It is an accidental (or is it?) property of a bridge that when it fails the structure will be bent, the metals will be stressed, and it will hit the ground leaving marks. Unfortunately when a software system fails it does not neccisarily leave a trace. Unless the system logs out what happened as it failed there is very little left for anyone to piece the situation back together.

Gathering software requirements removes all of the accidental properties of the object and leaves just the essentail ones. Sometimes we want those accidental properties to remain because we use them to reason about the world around us. The hard part is that until they are gone we might not even realise that they are not essential to the system, but are *essential* to our *use* of the system.

So maybe this is an argument for developing software based on uses of a system, rather than based on the properties of a system. Thoughts? I think the jury is still out on it.

Comments

beer

December 2007

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
Powered by LiveJournal.com