Lost in Abstraction

There are a million and one post as to what makes a good programmer/developer. Knowing how to find answers is one of those top criteria. I used to think (though shallowly) that being able to use Google was a good place to start judging. The more I thought about how we use tools, however led me to believe that there are two underlying competencies: Abstraction and Translation

Abstraction

Making objects and classes and decoupling and all the jazz is fine once you get to the stage of actually designing an application. That it not the abstraction I am talking about. The abstraction I refer to is the ability to pull out general principles from specific instances. For example, when you search for something in Google which does not appear in the first two pages, how confident are you that you can find what you are looking for? Are you able to abstract out the bigger picture and re-scope your search based on your initial findings or do you give up? As someone without a degree in computer science, I am often at a loss for the precise technical word for a general set of concepts.

Intelligence is being able to traverse the tree up and down in terms of generality and specificity. In essence to be able to cut away what is unnecessary, take what is left and reapply the core to something else. If all of this is too vague, let me give an example.

Let’s say have a co-worker. I mean, I do have a co-worker, but this is just an example. We have a meeting to discuss how we should implement a business rule. If your first reaction is to talk about web control functionality, you are starting on the wrong level. During one such meeting a co-worker asked “How are they going to key in the values?”. This might seem like it has nothing to do with abstraction, but it does.

Some people are so tied to a technology, or what is in front of them that they are unable to talk about the abstract

The reason why this skill is important is because it allows you to interact with the second necessary competency for quality development which is Translation.

Translation

I purposely chose the word translation over interpretation for this very reason:

Every translation is also an interpretation, but every interpretation does not include a translation

Translation is a more complicated competency. Here is a simple example. Looking at a photo of Man Ray’s, you can interpret the photo and ascribe to it a meaning wholly of your own. It can be totally internal without reference to the creator, sometimes with little reference to the work itself. Translation requires that one’s interpretation takes place within a framework that has a verifiable connection to the origin of the phenomenon. While there is seldom, if ever, a right or wrong translation, there are better and worse translation. We then settle on the best translation available. Referring to my earlier post: Translation is an ethics.

In development, translation occurs on several levels which is why it is vital to quality development. Translation occurs first in the gathering business requirements and then turning those requirements into business rules. As with translating natural human languages, there is seldom a one to one ratio of input to possible outputs. We take requirements and filter out the sediment to examine what are the essential rules.

Those business rules then become translated again into models and architecture. Good database design is based on translating actual business needs into properly designed schemas. Classes are then used to translate rules and data into applications. I realize this is all very simplified, but the concept is still there.

Put Together

Abstraction and translation then allow us together to move away from previous experiences (i.e. previous applications, meetings,etc) to gain insight on the current project. Quality developers know when to stop abstracting out, they know when they have reached proper abstraction and are then able to translate and integrate that abstraction with the current application parameters. Frameworks are an example of how this is put to work. The .Net framework is built basically on the most common set of classes. Microsoft has abstracted out the majority of functions necessary to program applications and has translated/compiled them into a framework. While some may argue that there is not enough abstracted out, that again is subjective argument, based on better or worse translations. Both C# and VB are translation of the very same basic concepts.

So now what?

As developers we need to develop these skills constantly. It is easy to become comfortable and stop abstracting and translating. In the worst case scenario we rebuild the same application over and over again. We make the same mistakes because we never take a higher view of our work. In less noticeable ways, we succumb to boredom and malaise by becoming lazy at re-examination of our work. If we consider our work done as soon as it works we will eventually end up in the worst case scenario. Once something actually works we need to re-examine what we did to make it work, see if it can be refactored for better performance and see how the whole works together. What can be applied to the next application, what can be used to maintain existing applications.

For me, this all comes before being able to write the fanciest hashtable.