I have spent a fair share of my professional career as software developer and consultant. And I see very often that a little thing called abstraction is overlooked too often.

In my day-to-day work, I engage with other consultants and people that work in the departments I’m creating software for. I love this initial phase of discussion in which everybody is allowed to share her or his opinion, problems, stories and anecdotes. (Yes, I really like to know everything.)

But sometimes, the core of a discussion goes wild. Instead of discussing the actual day-to-day problems the end-users have, the discussion circles around file formats, how to send & receive files or solutions with the minimum time of development.

If it really goes bad, participants leave a meeting with feelings of distrust, confusion and sometimes resignation. This is problem in the long run, because the users abandon the technology department and try to fix problems on their own.

Now, what is abstraction?

Abstraction is like a friend everyone always had, but no one knows it’s name. I can make that friend unveil with a little trick. Just answer the following question:

How does a TV work?

My answer to that question is: A TV receives a signals through an antenna, displays images on a screen and creates some output through the speakers. It is possible to switch TV channels too.

The magic about abstraction is, to be able to explain the wider attributes and functions of a system, I don’t have to explain details. For example, I don’t have to explain how the signal is transmitted from the TV station through the air. Nor, I don’t have to explain how the signal is decoded into moving images.

Abstraction is the process of removing details of objects or system to make it easier to focus attention on details of greater importance.

Why is it important?

I don’t want to beat around the bush with that answer: Abstraction is important to prevent that a discussion gets lost in details.

This is especially important when team members join the discussion, who don’t have a technical background. Of course, if you talk with a TV technician about the inner workings of a TV, the technician probably becomes excited and invites you for a drink.

On the other hand, when I talk to a graphic designer about the binary format of an image file. Then, the conversation will come to an end in the blink of an eye. And, that is totally fine – because it’s a detail that has nothing to do with the actual problem the graphic designer faces.

That’s the reason why I try to abstract the user’s problem to a level that represents the user’s experience. Geeking about details of technology makes the most fun with people who understand me anyways …