Interpretation versus Imposition of Meaning

Applications do one more thing in the realm of creating meaning: They impose themselves. The difference between interpretation and imposition is that interpretation is passive. It is something that we (or a system) does with data to try to find additional meaning in it.

As we can see in Figure 8.4, applications are not just passive processors of data. They participate, or, in other words, impose themselves on the world. That's the point. Sometimes this is direct, as with an application that opens a garage door or drops the cadmium rods in a reactor. More often it is indirect, but has just as much impact. The application says to move the raw material to production line 3, and sure enough the material moves. Or, as in a movie I recently saw,^[40] one of the protagonists got into an argument with the other protagonist, which resulted in the second one breaking into the bank records of the first and causing him to be declared bankrupt. Despite his protests, the bank clerk wouldn't loan him any money, because "the computer says you're bankrupt."

Figure 8.4: Applications affect the world.

However, applications, as we currently know them, run via "hard automation." Recall Chapter 2, in which we spoke of hard automation in the factory. Imagine a jib that drills holes in doors to accommodate hinges. Say you've been using the hinges in Figure 8.5 for years and you decide to automate the hole drilling. Someone builds a fantastic rig with gears and tracks and pulleys and the like, and sure enough, it drills the holes in the pattern you need, without human intervention.

Figure 8.5: Door hinge with screw holes.

Then you get a new supplier of hinges. These hinges look like the one shown in Figure 8.6. You have to bring the mechanic who built your first automation back to change the gears and tracks to drill for this new setup. You then have to test the new setup. And unless you completely duplicate everything, there is no going back, and no switching back and forth.

Figure 8.6: New door hinge.

You may wish you had invested in flexible manufacturing, where you load a description of the hole pattern into the system and the system, without hardware change, switches to the new pattern and drills it.

Applications are more like the inflexible drill rig than something you would expect from a product called "software." I worked on a manufacturing resource planning project once where we had to change the field length of part number from 10 characters to 25 to accommodate the needs of the defense industry. You might think this would have been an afternoon's work, because it was an "easy" change that didn't touch the semantics or any of the logic, "just" the field length.

As only those of you who have had to work with the internal functions of large legacy systems can appreciate, this was a million-dollar change. Not only every screen and report had to be changed, but also every intermediate file and transaction. Most of the programs in this system of 10 million lines of COBOL code were affected. And of course what really wreaked havoc was the "Well since we're in here making these changes anyway …" kinds of additions that kept coming up.

We intuitively expect software to be "soft," that is, easily malleable and changed to fit our needs. However, the opposite is true. In the next section we review what causes software to be brittle and how business rules changes that.

^[40]Changing Lanes, Paramount Pictures, 2002.