Blog concept: Sketchy optimisations

Recently a colleague was showing me a concept he was working on. He drafted a change in a fight against so-called 1+n-queries (actually for some reason unknown to me they’re called n+1 queries, but my head isn’t able to process the problem with just one more query after n queries…); in software development using ORMs like active record it is quite easy to make a single database request objects that when a presented within a view trigger other queries for every object because it has a relationship. Round trips to databases are generally bad as they take time.

For his change, he introduced a new class that we could seemingly reuse, with a just another (a bad code-smell) declaration of relations between objects and whether these should be preloaded when retrieving the primary object. This was in response to indeed a quite bad part of our code that entailed returning objects with counts of selected associations, but instead of counting these in the database, the current code was actually loading all these associations and filtering them in code.

Sometimes there is obviously bad, every fix would be an improvement. And sometimes one can think of an even better but more complex fix. But all too often, the complexity, sometimes obfuscated by an abstraction, isn’t worth it.

In our case it solved the problem, and was perhaps even a better fix in terms of query reduction, but while the new code was presented as an abstraction it didn’t seem to be ready any time soon to cover a multitude of other similar but slightly different problems. And that is the litmus test for abstractions: does it solve similar problems, if not, it is a bad abstraction. The logic might be smart. The performance slightly better (although imperceptible), but the newly introduced complexity should be really worth it, and it this case it really wasn’t.

Sometimes you need to look at your code and think, if I’d read this a few months from now, would I still get what is going on here? And if I make an abstraction, do I foresee how I can utilise it to fix this different problem?

Working on complex problems can be enticing, the idea of a more optimal solution, a nice “abstraction”. But is it worth the code? Is it worth the complexity? I’ve seen too many code bases where sketchy ideas ended up being used as early drafts of something grand. But these sketchy optimisations often just add to the cruft, plastering the complexity without really solving a bigger problem. Prefer the easy fix, until you learn what the bigger problem really is.