Abstractions, Performance, and Documentation

Abstractions are good, when it comes to software development. There are any number of reasons for this, from Loose Coupling, to SOLID, to, well, just google it if it isn’t already obvious to you.

Let’s add a touch of nuance though, because, after all,Nuance is what we do in Software Development .
Abstractions are mostly good when it comes to software development.

The key here is the ever-present tradeoff between Flexibility and Performance. Or, to put it differently, if you’re going through the “Make it Work → Make it Right → Make it Fast” sequence, and have somehow (hallelujah!) managed to get to the Make it Fast stage, well, this is almost exactly where the abstractions can start biting you in the butt.

Sometimes that one optimization you need to make is hidden behind an interface, and you really don’t want to compromise the interface (because the abstraction it provides is ridiculously valuable everywhere else in the code). Or, for mechanical sympathy reasons you want to tweak a specific package implementation, but that’ll make replacing it difficult down the road.
Or…, well, we don’t need to go on. The point here being that the benefits of abstraction can turn into a curse at the edge.

There really isn’t an easy answer here. Sometimes you go ahead and mess with the abstractions anyhow, and sometimes you live with the performance hit. Either way, you end up with a bunch of issues.
The key, however, is that as you go down this road, be sure to document your decisions! Regardless of whether you took the hit or not, documenting it is key, for the sake of the future generations of developers who are going to look at your code and wonder why it does (or doesn’t do!) what it does…