Abstraction

Abstraction is the ability to build models. For example, you are dealing with a problem to be solved. The problem has its own details and nuances. To solve it, a human mind tries to build the model of both problems and then the solution. Both the problem and solution space can be made as specific or as generic. How specific or generic depends on the person doing the mapping. Depending on individual inclinations and capabilities, it might be very specific or very generic.

Abstraction has to be handled carefully in software development or for that matter in any problem-solving exercise of the world. The right level has to be achieved otherwise it will lead you to a rat hole, in the case of both under and over abstraction.

Let's look into the problems with under and over abstraction.

Perils of over abstractions

At times we do over abstraction. We generalize the problem and solution space beyond what is needed immediately or in near future. It's like "Solving all the problems of the world in one go." From an analysis perspective that thinking is good but from practical implementations that becomes challenging. Some of the problems of over-abstraction are:

• The mental models become very complex and it becomes difficult for teams to communicate with each other on equal terms. Not all people in a development team work on the same plane of mental models. The common denominator is the lowest plain with every detail very specific. As the plane moves upwards, the specifics start morphing into generics and you start losing people in the discussion. This is not a statement about the capability of people, it's just about different kind of people. The best implementers exist in the lowest plains and they are driven by deliveries and not by abstract art. Factor their existence and you will be rewarded with actual deliveries and not high octane discussions.

• Cost of initial development will be higher and this leads to delay to time to market. The highly abstracted system goes more into the realm of art than science. Specifics are replaced with generics. And it will burn a lot of money initially. 

• You have to very careful in getting the highly abstracted systems right. It's a tight rope walk. You are shooting a Sun and a minor variation in the angle of the shoot will make you land light years apart. Once the system gets done rightly, it will be a huge reward also maybe for years to come. 

• Testing infrastructure is complex to build as this requires the same level of thinking as was put into building the architecture. 

Perils of under abstraction

Under abstraction, if have to be explained in simple term, it's hard coding. If the user is born in 1990 only then this program can calculate the age, nothing more nothing less. Mental models are very easy as there are no mental models. What you talk can be seen in the code in black and white. 

• Initially, development will happen very fast, but as the delivery nears, the perils of under abstraction will start to show up. It's like running a 100 m race and you put all your energy into it. The moment you are at 80 m, the management comes and says that you have to continue the race as it has been converted into 400 m race. And who knows what will happen at 350 m. The new use cases will start falling apart and more than anything it creates animosity in the teams. 

• Under abstracted systems are very easy to get right and then they become completely wrong. It will lead to a black and white situation.

Under abstraction is not bad in situations when you are dealing with one-off problems. Make sure though that these are one-off problems. Don't try to paint Monalisa in every one of your adventures. Moreover, a person in his lifetime builds only a few masterpieces so focus your energy accordingly.

EndNote

Most of the time it's difficult to figure out what is the right level of abstraction. At times, the decision taken with present facts may not turn out to be correct for future. That's where it gets more in the realm of art and intuition and requires experience to be applied.

The business need or the possibility of big markets at times leads to building highly abstracted systems. At times, you are shooting the Sun. Make sure you have a core of strong executioners with a heavy artistic bend. People who love delivering as well as talking about Picasso and they have the right mandate and enough resources to play with. These ventures are like a symphony, and the difficult part is, most of the things will not be visible to naked eyes. If there is one big problem in the Software world, it's the inability to visualize on a common ground both problem and solution space. Each one carries their own models, that's why communication is key in building the right ecosystem.

Photo Credit: By romana klee from usa - sammati tarka prakarana, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=59461928