Stop over-abstracting

Because developers are usually highly intelligent, they are very good when it comes to abstracting things, be this: 1) generating base or generic classes to inherit from or reuse; 2) generic or overloaded functions called with arguments instead of standalone ones; or 3) reusing code under multiple technologies even if it’s difficult to achieve this.

While such skills are very important in the programming world, it is also very important that they are not overused in the commercial world!

From my personal experience I learned that very often it’s better to just not abstract things than to do it. (I know this will probably start a big discussion that can never end or at least will turn some of my readers’ minds into generating complex comments that they cannot post due to WordPress rules – !@#$%^&*).

My reasons are simple though:

  1. Many times we abstract things assuming that the customer(s) will request similar new features in the future, and that in this case we would be able to develop them easier; but we spend a lot of time with the initial setup, while it’s not certain that it will bring any value eventually – customers are unpredictable – and often it turns out that if we wouldn’t have generalized things we could have delivered – at least the first version of the product – sooner (sometimes sooner than our competition!)
    • Of course, if later we would really need refactoring, we could ask the customer to pay some extra for it, whenever he or she requests a similar feature, explaining him or her about the easier maintainability when not allowing code duplication (money that it would have been difficult to request initially).
  2. Other times there is also a personal value concept involved, such as generated by the feeling of doing things the way we think it’s better: we like to abstract things so much that we want to do it regardless of its commercial benefit.
  3. While from a technical perspective, I observed that having some duplicated code or not sharing code under different technologies comes indeed with some challenges and harder management, but it’s not impossible to live with it: you just need extra care and some good tools during maintenance times!
    • Moreover, many times the customer(s) will request small changes applying only to one or some of the “duplicated” cases, and if we would have done it with too much abstraction it would have required so many argument chains to be passed along the internal code routes to obtain the intended behavior that we say to our customer that it’s not possible to do it (and he or she will surely not believe nor understand us, and for good reasons – the requested changes were, in theory, so simple – but only if the code was separated!)
    • Finally, note that sometimes you just can’t share code, such as if you develop apps or components in a multi-platform+native way, such as if you develop – for example – for Windows using C#/C++ and UWP/WPF, for Android using Java/Kotlin, for iOS using Swift/Objective C, and for the Web using TypeScript/JavaScript and a framework like Angular (and maybe later also for holographic computers using Unity 3D and its C# subset): the cotemporary programming languages share – at their core – the same concepts, but they require different syntax, and the maximum you can reuse is the logical design of the app and a few common looks and supported input types (although the latter seem to also change very fast too: from 2D to 3D, and from mouse to touch and air gestures – so it’s even easier if you don’t share UI code at all).
      • Even if you accept no-nativity for some targets, such as deciding to use C# and Xamarin to get your single codebase app working on UWP, Android, and iOS devices with ease (although this will generate other problems, when corner cases appear, you’d see), you will probably still need a different programming language for the Web and later probably something completely different to support 3D holograms properly.

So do not do your best, and worry less: that’s my advice today, and I’d give it to myself as well, if I could go back in time a decade or two!

This does not mean, though, that you should never abstract or refactor your code. Instead, it means just that you should do it properly: analyze the opportunity of any possible abstraction before you actually apply it!

Advertisements

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in Architecture and tagged , , , , , , . Bookmark the permalink.

One Response to Stop over-abstracting

  1. Pingback: Avoid extracting internal libraries | Code {Sections}

Add a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s