Wednesday, August 09, 2006

Land of a 1,000 Abstractions

One of the tools we have in our design tool box is the application of abstraction.  Abstraction is simply de-cluttering the set of things that we have to think about by excluding those things which are not relevant.  We might be dealing with building a system to handle the training for 10,000 individual employees.  It is just not possible to reason about these 10,000 employees, one by one.  In an ideal world, we would start off and look at the first few dozen or hundred employees and recognize that there was an emerging pattern.  Every employee that we looked at had a first name.  Every employee that we looked at had a last name.  Every employee had a manager.  And so on.  We would build an abstract employee that had all of the characteristics that we thought were important.  If we built our abstraction correctly, we can now reason about this abstract employee and apply all of the reasoning about that abstract employee to each of the 10,000 employees.    This can be an enormous time saver.

When we use abstractions, there are several things we have to keep in mind.

First, every abstraction comes out of a particular point of view.  What that means is that a given abstraction is only as good as the usefulness that provides.  I can’t tell you the number of times I have been in design reviews in which two people representing two similar but nonetheless different points of view battled it out over a particular abstraction.  Both were right and both were wrong.  There are hundreds (and perhaps even thousands) of possible attractions that we could create for employees, each of these depending upon the specific point of view that we wanted to support.  Each of these abstractions is equally useful and equally useless.  In my experience there is absolutely no value to be gained in arguing about the value of a particular abstraction in isolation from its associated point of view. 

Second, every abstraction is incomplete.  The very definition of the abstraction means that we are leaving things out.  If we’ve done our job properly, the things that we have left out are not relevant to the particular point of view that we are trying to pursue.  The reality is that we never quite do our job right and there almost always are little things about the real world employees that we should have included within our abstraction.  This is not a cause for lamenting and pouring ashes over our head.  It is a cause for being cautious about the abstraction and coming back periodically to test the abstraction to make sure that it is still useful and is still representative of the important parts of the real world population that we are trying to model. 

Third, one of the things that abstraction does for us is to open up possibilities.  One of the things that I’ve done a number of times in my career is to look at an existing application to the end of extracting the essential functionality of the application as a series of requirements.  The requirements are an abstraction of the existing application.  There are a great number of different concrete implementations that would satisfy the requirements.  These concrete implementations might differ with respect to the platform or the technology or the programming language or the Web versus rich client dichotomy.  The abstraction allows us to reason about the requirements without having to worry about the specifics of any particular implementation.  That can often lead to some additional insights that might not be visible if we focus on a particular platform or technology or delivery approach.  Later, we can look at the question of what is the best mapping from the abstraction to a concrete reality.  If we’ve done our job right, there ought to be a number of different possible concrete realities that we could pick, comparing and contrasting to understand what would be the best approach to realizing the abstraction.  [I choose to pay no attention to the chortling coming from my readers; this is my fantasy and I intend to enjoy it; I get quite enough “real world” ugliness in my work and I do not need to solicit more of it.]

Fourth, it is very hard to be pure in the construction of an abstraction.  Joel Spolsky wrote an excellent essay on leaky abstractions.  Ideally we would be able to take a clean horizontal slice that captured the essence of our target population without having to go into the gory details of each individual member of that population or how we might implement the abstraction.  The reality is that we (sometimes unconsciously) “cheat” and think about how we would implement a particular abstraction and that implementation thought colors the abstraction.  Again, this is not something where we should be assigning blame, but it is something to watch for as we go about our process of creating and reasoning about abstractions.

The bottom line is that abstractions are incredibly useful but if used without an understanding of these factors  abstractions can just as easily make our life much more difficult.



Post a Comment

Links to this post:

Create a Link

<< Home