Avoiding Hasty Abstractions (AHA programming)
Tags: programming, architecture, discuss, computerscience
Published: 2023-01-11 02:28:29

I have seen a number of posts recently expressing confusion and frustration with the AHA (Avoid Hasty Abstractions) programming principle [described by Kent C. Dodds](https://kentcdodds.com/blog/aha-programming). I've seen it suggested that AHA is redundant and solving a problem that could be fixed by just sun-setting the dictatorial axioms, arguing that AHA is just another prescriptive doctrine, or that DRY and WET were acronyms selected with purpose while AHA was just pulled out of a hat at random.

It definitely wasn't random. I should have explained. AHA is not a compromise between DRY and WET. It's not a _dogma_ at all. It's an _[aphorism](https://www.newyorker.com/magazine/2019/07/22/the-art-of-aphorism)_.

## There's more than one way to over-engineer a system

Getting hung up on _when_ is the _right time_ to abstract or _which_ is the _right abstraction_ is falling back into the arbitrary trap that DRY (Don't Repeat Yourself) or WET (Write Everything Twice) programming principles put us in. DRY is especially troublesome because while we are inherently pattern-seeking, we are also skeptical beings who are most critical of ourselves and to err is human. _Is this really different than that last method I wrote? Is this actually a pattern? Did I already write this?_ 

Why are we so self-critical? To keep ourselves safe by triggering the flight or fight response. In other words, when faced with rules that _demand_ adherence, we panic, over-self-scrutinize, the anxiety escalates, and we end up with a haphazard obscuring of data and implementation in a system with ever increasing entropy. In chaotic environments, we are so susceptible to authoritarianism that we [recklessly accept increasingly oppressive structure](https://www.theguardian.com/commentisfree/2020/jan/02/authoritarian-leaders-people-safe-voters) that provides the illusion of order. We don't make fewer mistakes with dogmatic principles, we make more and they are more complex. We're better off with pithy proverbs that allow us the freedom to _thoughtfully_ make mistakes. Mistakes in psychologically safe environments beget order by [prompting](https://kids.frontiersin.org/articles/10.3389/frym.2020.00080) us to _more carefully_ consider the next solution.

## Eureka!

The Aha! moment, or insight, happens when [the restructuring of a mental model](https://www.nature.com/articles/nature02223) for a problem triggers unexpected clarity resulting in the solution. _Somehow_, we know it will work. For insight to happen, we have to develop experience (contemplation, collaboration, Googling the answer, making mistakes, etc) and [take breaks to avoid rumination](https://hbr.org/2019/02/how-to-stop-obsessing-over-your-mistakes). Rubber ducking and writing tutorials are great methods for disrupting the brain's structure of a problem space.

When I said we should avoid _hasty_ abstractions, what I meant was that we should try not to abstract _impulsively_.

Thoughtful abstractions are _planned_. This can happen early—during the system's design—or more often, later, [when you need it](https://ronjeffries.com/xprog/articles/practices/pracnotneed/). Careless abstractions are almost always the result of abstracting for unknown scenarios—or when we code a pattern twice and immediately consolidate it into an abstraction before we've considered if the two patterns really serve a _single_ shared purpose and will continue to.

Don't abstract for the sake of abstracting, but don't do the opposite either! Manage complexity by aiming for simplicity and maintainability with the information you have. Make it work. [When it's obvious and transparent to do so: make it better](http://web.archive.org/web/20130803163743/http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf). 

## To ask why we bikeshed is to ask why the leaves fall. It is in our nature.

Coding in the spirit of AHA is about thoughtful design that considers the entirety of the system in a holistic way. Everything from psychological safety to algorithm efficiency will affect the integrity of the software we develop.

> [The structure of a system reflects the structure of the organization that built it.](https://martinfowler.com/bliki/ConwaysLaw.html)

The universe tends to chaos. It takes hard work to create peace and order. Being mindful with not only computational resources, but our energy—and that of our colleagues—is they key to limiting chaos in the programs we code.