Thomas Maroulis

all good abstractions in moderation

There is one thing that as engineers we tend to be quite fond of and that is abstractions. There is good reason for that. Abstractions are wonderful things. They allow us to get a complicated problem and break it down into manageable chunks that can be tackled individual away from the overwhelming complexity of the whole. They let us reuse components instead of writing a custom solution for every variation of the same problem. They are so good in fact and we rely on them so much that we often tend to overdo it and try to shoehorn them where they do not belong.

it’s in the details

An important detail of abstractions that too often gets forgotten is that making a good abstraction is a hard problem. One has to think of all the possible use cases that the abstraction will have to cover which is difficult in its own right. Worse, adding a missed use-case to an already implemented abstraction frequently results in horribly mangled code as the existing logic is twisted to account for something that was not part of its original design. That is, if it’s not outright impossible to add the missing use-case in which you end up with two different ways for doing the same thing. One via the original abstraction and one via a “workaround” for what the abstraction could not handle.

The solution to this is to recognise that not everything has to be a framework and also that predicting the future is hard. Designing something that can handle today’s requirements and also tomorrow’s can backfire spectacularly if tomorrow’s requirements end up changing. Which will happen… often.

the fine line between a good, easily expandable design and gold-plating

Rather than trying to make a single solution for all your problems it is often better to keep a minimal common layer and partition your business logic vertically at first. The common layer will have the functionality that is unlikely to change and will be initially small enough that you can easily expand it as needed. After the initial implementation you can then reevaluate the design and extract new common layers of the vertically partitioned business logic.

The important detail is that you are no longer trying to predict your future needs, but are rather creating an abstraction out of logic that is already there.

If you want to read more on this topic this article does a good job at explaining this concept as well as a few others.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus