Thinking in the Abstract

A significant challenge in understanding Information Technology is getting used to thinking in the abstract or, put another way, using abstraction to think about, visualize, and articulate the virtual.

As vast and powerful as it is, software is intangible. It exists only as a series of executed instructions.  A piece of software might be so simple that it's like adding two numbers (x + y = z).  On the other hand a software system might be so sprawling and complex it's like decoding the human genome!    Not surprisingly, it can be very challenging to understand, to discuss, and to troubleshoot software problems.  In order to approach software...that is to design it, to break it down into smaller parts, to discuss with others what the software is doing, and so on, we use conceptual, or visualization, techniques to form an abstract concept of what the software does - what it can be used for.  Abstraction is the thought process wherein ideas are distanced from objects.

In class I used a mathematical formula example to illustrate, in simplistic terms the process of abstraction.  A concrete example of a mathematical forumal might be 2+3=5.  It's a solid formula that we might use for situations calling for adding those two numbers together....but it's a very specific, inflexible formula as well.  If we use x + y = z, an algebraic formula we can see that while we can still use it to add 2+3 we can also use it to add ANY two numbers together and so it is both more abstract and more powerful, more flexible.  We can make it more abstract by saying x ? y = z where ? may equal any mathematical operation (addition, subtraction, division, multiplication, and so on).  Thus this function is even more abstract and more flexible because we can use it to subtract, divide, or multiply two numbers together as well as add.  More power!   As we get too abstract, however, say a function that takes any series of numbers and performs any operation, we can see that it becomes too general, too flexible to abide by logical rules.

In class we also discussed how "machine" is an abstract way of describing an overhead projector.  Pitney Bowes serial number OP24579 is a very concrete specific instance of an overhead projector.  And in between those two extremes we can see classes or subclasses by which an entity, in this case an overhead projector might be described at different degrees of abstraction (i.e translucent overhead projectors, office equipment,  electrical machine, machine).

Abstraction uses a strategy of simplification of detail, wherein formerly concrete details are left ambiguous, vague, or undefined; thus speaking of things in the abstract demands that the listener have an intuitive or common experience with the speaker, if the speaker expects to be understood.
To design a basketball, a model of the Earth, or an animation of Cartman we might start with an abstract drawing of a sphere. To start to build a house, or an entire sub-division, we might start with an abstract drawing of building plans.

Here's another examle using a characteristic, or property, and a relation. We can talk of the colour red in the abstract. We can describe it vaguely or generally by giving popular varieties of red as in ruby red, fire engine red, maroon, its hue, its RGB colour code, and so on. When we think of something as general and undefined as "red" we can think, visualize, or speak in the abstract. This can be quite useful. Lots of different things have the property of redness. We can use the idea of redness to think of, visualize, and articulate all sorts of things. We can apply the concept of redness in myriad directions. Now apples, tomatoes, wine, and other objects that possess red as a property are specific. The indivdual cases of these objects have a unique and specific, or concrete brand of redness. When we speak of them we speak about individual instances.

Likewise we can speak of relations, action words, and processes in the abstract or the concrete. "Doing something" is an abstract phrase void of detail. "Punching George in the face" is concrete. A sales order process or a procurement process denotes two business processes which virutally every business must manage effectively. In this sense these processes can be thought of in the abstract. But all companies have individual preferences when it comes to managing their business processes. When we talk specifically about how a company implements their processes, what business terms they use, and so on, we would be talking about an instance of that business process. When a customer service representative pulls your file to look over an old sales order they are looking at a concrete instance of that process at work.

Computer software is designed in the abstract. Concurrent, overlapping, and intersecting pieces of software begin as abstract plans. When they are executed the abstract pieces work together, apply templates, and collate specific data to become concrete instances that provide services and results.