December 09, 2004, 5:05 PM — One of the most annoying things about software is the name itself - 'software'. What a terrible name! Anyone who has spent any time in the company of application software knows that 'soft' is not an epithet that immediately springs to mind. Truly soft software would be flexible and malleable and easy to mold into different shapes. Does this describe software as you know it? Me neither.
Sometimes I think that software is a harder substance than the hardware it runs on. On Moh's Scale[1] used in the physical sciences I'd rate it a 9. Hard substances are those which, once formed into a shape, resists being reformed into a different shape. This sounds like a perfect description of a lot of application software to me.
Okay, okay, so I am over-generalizing again. It is not quite as simple as I am making out. Things never are in this business. Here is the grain of truth on which this mountainous generalization has been built:
All software applications have a level at which they cease to be soft
and become as hard as the hardware they run on.
Examples? Take database applications. You specify your fields - your schema - and then you create screens that allow data to be entered into those fields. Once created, the schema structure becomes very hard, very fast. Modifying fields once an application has been built around the schema is not simple and thus not cheap. Software turns to hardware.
Take spreadsheets. You have a spreadsheet and you wish to take a number that appears on a web page and splice it into a cell. Well, cells don't easily pull numbers from web sites and the number on the web site is not easy to pull out of the page because it has been 'hard coded' there. Not simple and therefore not cheap. Software turns to hardware.
And so it goes. We are surrounded by applications - either off the shelf or custom designed - that exhibit a distinct hardening behavior over time. I am reminded of the process by which the Earth itself formed. In the beginning the surface was soft and malleable. Stuff moved around and ran into other stuff. The process led to big troughs we call oceans and big peaks we call mountains. After a while, everything hardened. We can no longer move the mountains or the oceans. We have to go through them or around them or over them.
And so it is with software. Applications are only truly soft during their formative phase. Once deployed, they harden into the software equivalent of the Appalachian Mountains. Once that happens, you have to plan on going through them, or over them, or around them. It is not cost effective to reshape them.
Of the three possible routes to overcome immovable software obstacles, tunneling is the most interesting. Using tunneling, you use some aspect of the system to achieve some effect for which it was never designed. In a database application, you could use the fourth line of an address field to hold a customer status code. In a spreadsheet application, you could use the 'goods description' row to contain useful numbers. And so on.
We are surrounded by applications that are awash with these little tunnels - semantic tunnels. Clever little workarounds developed by their users to get over the non-softness of the software applications themselves.
There is a pattern here. Users are fountains of innovation when it comes to working around limitations in application software. It should be possible to capture these tunneling patterns in a way that allow application designers to soften their applications and avoid or reduce the need for these tunnels.
Why is this desirable? It is desirable because the semantic tunnels are known only to the users - not to the applications themselves. Consequently the degree to which individual systems are independent of any particular user's skills/knowledge is easily over-estimated by management. The tacit knowledge of all your tunnels and where they lead, walks out the door every day at 5:30.
The only truly soft thing in any organization is its gray matter. Everything else, including software, is just hardware at the end of the day.
[1] http://invsee.asu.edu/nmodules/Carbonmod/mohscal.html
