Escaping abstraction hell
Tags: productivity
Published: 2019-07-19 13:59:49

---
title: Escaping abstraction hell
published: true
tags: productivity
canonical_url: https://makingloops.com/abstraction-hell/
---
<img src="https://makingloops.com/public/abstraction-hell.png" />

You’re probably a lot like me when it comes to design decisions around code.

You _like_ clean code.

It is satisfying to both read and write, your teammates appreciate it, and it makes your application easier to work with down line, so **you put a lot of effort into it**.

But upon the this purity of intent, the psychological gremlin of [perfectionism](https://makingloops.com/perfectionism/) often rears its head.

Driven by a subconscious shame and fear of failure, it’s becomes the obsession to find _the best way_ to go about your task at hand.

It’s tough _not knowing what you don’t know_.

Of course, a quick web search to find the best way of doing something is a great thing, and it’s how our software improves, but what has happened to me, and likely you too, is that it becomes a _worm hole_.

Scanning one browser tab on how to use Mediatr then spawns three more on CQRS, [keeping controllers thin](https://makingloops.com/why-should-controllers-be-thin/), and [the repository pattern](https://makingloops.com/why-should-you-use-the-repository-pattern/).

You realize you weren’t following the single responsibility principle and that you have a _command_ inside your _query_, so you’ll first need to refactor that.

As you refactor and are at the same time drinking beyond your fill from Google’s tit, you come across domain driven design and decide it would be better to host an event storming session with your team before you can _feel comfortable_ implementing the original small task you were assigned.

**This is a hell spiral.**

It doesn’t end, and rather than finishing your task, you instead just add a bundle of abstractions that _in theory_ reduce coupling, but are likely untimely and low in value to your team and your company.

This is usually because advice articles are written with a very specific problem context in mind which is often not _your_ problem context, so you’re building your application _based on the needs of some other application_.

It’s also a lot like waterfall vs. agile software development.

The perfectionistic obsession has you putting the cart before the horse trying to _predict eternity_ rather than _just finishing your task_.

The best architecture promotes agility (ease of change), but if you haven’t had a need to change anything about it, _you’re prematurely optimizing based on a hunch._

## What to do instead

First, don’t beat yourself up. This sort of _architecture thrashing_ is something just about every developer I’ve ever met has done.

With time and experience, you will be able to make faster and better predictions for what kind of design a certain feature should have, but until then you can use a much simpler approach.

Start with just getting your feature _working_.

Put aside all of the _shoulds_ the software world is tossing onto your shoulders and just get it working in the simplest way possible.

Perhaps begin with one single method and a set of comments that break the feature up into a high level algorithm.

```
 private void purchaseItem()
 {
     //set up payment gateway api client
     //process payment
     //generate receipt
 }

```

After you have it working, commit to _maybe_ 30 minutes to an hour on basic _tidying_.

Focus this time on making it easy to understand (small methods, clear names), and on aiming for the single responsibility principal with your those methods and their classes.

That’s it.

Move the hell on.

And here is the important bit – you can _trust_ that when your feature begins being used in the wild, **the opportunity to iteratively improve the design will reveal itself organically**.

Rather than toiling over upfront psychic predictions, your optimal design _emerges_ via actual pain hot spots.

So you end up with a design that is more congruent with need, and you finish your features faster, with more ease and enjoyment.

## Going further…

If this resonated with you, I encourage you to take a look at my [article on boundaries](https://makingloops.com/boundaries/) to deepen your understanding of other personality traits that could be affecting your growth as a developer.