Tension and Intention: Shifting Meaning in Software

If a software system is designed for one particular purpose, the data structures will have one set of intended meanings. These will be the meanings which the software developers anticipated would be needed by the user community for which the software was built. This set of intended meanings and the structure and supported relationships make up the “domain” of the software application.

When the software is actually put to use, the user community may actually redefine the meaning of certain parts of the syntactic media defined by the developers. This often happens at the edges of a system, where there may exist sets of symbols whose content are not critical to the operating logic of the application, but which are of the right syntactic media to support the new meaning. The meaning that the user community projects onto the software’s syntactic media forms the context within which the application is used. (See “Packaged Apps Built in Domains But Used in Contexts“)

Software typically has two equally important components. One is the capture, storage, retreival and presentation of symbols meaningful to a human community. The second is a set of symbol transformation processes (i.e., programming logic) which are built in to systematically change both the structure and possibly the meaning of one set of symbols into another set of symbols.

For a simplistic example, perhaps the software reads a symbol representing a letter of the alphabet and it transforms it into an integer using some regular logic (as opposed to picking something at random). This sort of transformation occurs a lot in encryption applications, and is a kind of transformation which preserves the meaning of the original symbol although changing completely its sign (syntactic medium).

When we push data (symbols) from a different source or context into the software application, especially data defined in a context entirely removed from that in which the software was defined and currently used, there are a number of possible ways to interpret what has happened to the original meaning of the symbols in the application.

What are some of the ways of re-interpretation?

  1. The meaning of the original context has expanded to a new, broader, possibly more abstract level, encompassing the meanings of both the original and the new contexts.
  2. Possibly, the mere fact that the original data and the new data have been able to be mixed into the same syntactic media may indicate that the data from the two contexts are actually the same. How might you tell?
  3. Might it also imply that the syntactic medium is more broadly useful, or that the transformation logic are somewhat generically applicable (and hence more semantically benign)?
  4. Are the data from the two contexts cohabitating the same space easily? Are they therefore examples of special cases of a larger, or broader symbollic phenomenon, or merely a happy coincidence made possibe by loose or incomplete software development practices?
  5. How do the combined populations of data symbols fare as maintenance of the software for one of the contexts using it is applied? Does the other context’s data begin to be corrupted? Or is it easy to make software changes to the shared structures? Do changes in the logic and structure supporting one context force additional changes to be made to disambiguate the symbols from the other context?

These questions come to mind (or should) whenever a community starts thinking about using existing applications in new contexts.

Packaged Apps Built in Domains But Used In Contexts

Packaged applications are software systems developed by a vendor and sold to multiple customers. Those applications which include some sort of database and data storage especially are built to work in a “domain”.

The “domain” of the software application is an abstract notion of the set of contexts the software developers have designed the software to support. While the notion of “domain” as described here is similar to and related to the notion of “context”, the domain of the software only defines the potential types of symbols that can be developed. In other words, the domain defines a syntactic medium (consisting of physical signs, functions and transformations on those signs, and the encoding paradigm).

But the software application domain is NOT its context. Context, when applied to software applications, is defined by the group of people who use the software together.

There’s a difference, therefore, between how developers and designers of business software think about and design their systems, and how those systems are used in the real world. No matter how careful the development process is, no matter how rigorous and precise, no matter how closely the software matches the business requirements, and no matter how cleanly and completely the software passed its tests, the community using the software will eventually be forced to bend it to a purpose for which it was never intended.

This fact of life is the basis of several relatively new software development paradigms, including Agile and Extreme Programming, and the current Service-Oriented Architecture. In each of these cases, the recognition that the business will not pause and wait while IT formally re-writes and re-configures application systems.

One of the shared tenets of these practices is that because the business is so fluid, it is impossible to follow formal development methods. In SOA, the ultimate ideal is a situation where the software has become so configurable (and so easy to use), that it no longer requires IT expertise to change the behavior. The business users themselves are able to modify the operation of the software daily, if necessary.

%d bloggers like this: