Abstraction, Abstraction, Abstraction

Publicado por Alexandre Cunha
02/11/2010
Categoria:
Tags: ,

Let’s talk about something that is (or should be) very recurrent in software development: abstraction.

During all those years as developer abstraction is something I keep improving over and over and that I see the greatest impact on my coding abilities.
Unfortunately abstraction is not something you can learn by simply reading a book. There’s no book or course that will be able to teach you how to abstract.
You can read a book on some abstraction techniques but the only way to learn abstraction is by… well, abstracting! You really have to exercise it and think about what you’re doing on a daily basis to see any improvement.

In a way this is like learning sports. At first you learn a lot of things and improve your dexterity very quickly. Then you get to a plateau and start feeling you’re not really learning. Your game skills are ok but not superb.
From there you could become a recreational player and occasionally amuse yourself with your amateur skills. You could even play everyday just as a hobby but you wouldn’t improve overtime so you would never become a professional player.

A different path you could follow is to play everyday and really try hard to improve. You must study new techniques, try to use them, even if that means failure sometimes.
You need to struggle with your limitations, understand them and everyday try to gain new ways of overcoming them. Every time you hit the ball you do it a little bit better than last time and improve on the little things.
Eventually you will become a pro. Then every year you would look back and see what a terrible player you were and how much better you are now.

That’s exactly the case with abstraction from my perspective. It’s something I’m always improving. I read Design Patterns (GOF) years ago and I have used almost every single pattern in that book.
Still I learn a new tinny information every time I use it again. It could be a small implementation decision (which doesn’t change the pattern) bringing new interesting insights or just simply applying it to a whole new problem I never thought before.

Sure, you know how to use Singletone or Abstract Factory (do you? really?). But knowing how to use it doesn’t prove you know how to abstract. Even worse, it does not improve your abstraction skills because all you’re doing is hitting the ball over and over but not looking if it’s falling in or out of court.

Abstraction is not a mechanical skill. It’s not something you simply learn by repetition. You must realize how the abstraction process works and what are the consequences of your decisions in your code. With time you learn about those decisions so you don’t have to try them anymore. You can predict the consequences because you’ve been there before and suffered so hard you regretted that decision.

A lot of people when receive a task to fix a bug or add a new feature, they go and start looking at the source code to find where they can fit a new if-else statement.
Then they find another place where the same if-else statement is needed and junk it in. Then do it as many times as needed. I’m sure you’ve seen this pattern before. It’s called: if-else to death.
You can’t solve a problem by simply writing code. The code you write must be a consequence of your solution, not the solution itself.

There’s a big difference between going straight to the code and fixing it compared to looking at certain problem and use your abstraction skills to find a solution and then going to the source code.
I’m not advocating you have to draw a hundred UML diagrams and insert dozens of new patterns in order to add a new feature.
What I’m saying is that the solution to your problem is not at the code level but most of the times at the abstraction level your code represents. If you don’t have the time and look why your abstraction is wrong you will never be able to write the correct if-else that fixes it.

When I interview people I used to ask about Design Patterns and how they were using it, trying to measure what kind of abstraction skills they had.
I don’t anymore. People learned that answering those questions would give them a better chance of success in an interview so they started reading a book or googling it.

Nowadays knowing Design Patterns is not a valuable skill anymore because most people heard about it and will begin drooling something if you ask.
I don’t care if they know patterns I care if they know how to abstract and 95% of all developers have no idea what that’s all about.

Here’s a very simple example:

Think about a tree structure that has nodes and leafs. Every node can have multiple children and every children has a father (only one father – this is not a graph!).
Nodes with no children are called leafs.

How would you abstract it?

A lot of people will come to this solution:

Which is fine.
But I notice most people will take +10 min to solve it. Sometimes they will try for 10-15 min then give up because it’s sucking up too many brain cells.
A lot of people don’t even try to draw something (they think abstraction is for nerds).
If you’re a professional player it should take you less than 1 min to do it. Seriously!

When people throw this diagram at me, I usually ask them: what if I need to represent a leaf, which will never have children? What if I want to represent that in my diagram? There’s a simple solution to that but it’s no obvious. It requires a certain level of abstraction and good thinking to find out (it’s not that complicated either). But most people die in their chairs thinking about it and simply give up after 30 minutes. A pro would do it in maybe 10-15 seconds.

I’m not saying you have to think faster than light to be a good developer. I’m saying if you’re really working on your abstraction skills on a daily basis you easily know your way when abstracting simplistic problems like this.
If you can’t do it in less than a min then work hard on your abstraction skills because all the pros can!

Being able to quickly come up with a solution like this is crucial when writing code. You need to be able to abstract what you’re doing without going for a piece of paper or any UML tool every 5 mins.

Abstraction is really hard. It took me years to learn how to do it properly and I still feel lost sometimes. I still look at my past abstractions in old projects and feel like crying.
But that’s how it works. You get the feeling you’re actually getting good at it when you start hitting the ball so often that it becomes a natural skill, part of your coding skills, just like writing an if-else statement.

Then you mix it up with your code writing abilities and you will be able to come out with something really beautiful.

1 Comentário

  • Reply

    Por Ronaldo em 26 de November de 2010 às 19:19

    Very nice post.
    We don’t really feel how much important abstraction is to our job. The ironic thing is: abstraction *is* our job.
    How early you notice this the better.
    We sure need to practice abstraction and learn from our own failures/successes the best path to follow.

    All the best,
    Ronaldo





Desenvolvido por hacklab/ com WordPress