Abstraction castles
“…some service maintained by one person that’s built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self.” [sic]
https://news.ycombinator.com/item?id=16201126
That Hacker News comment struck a chord with me, as I think the phrase “impregnable abstraction castle” perfectly captures something that is commonly encountered in software.
An abstraction castle appears as follows. An area of a codebase seems to develop into a fortification that is resistant to change, apparently designed to defend against all envisioned future scenarios and to keep out every encroachment of the outside world that the designers could imagine.
The abstraction castle is an unbreakable joined-up piece surrounded by a moat and a drawbridge. It’s difficult to isolate any single area for potential alternative use cases. Inside the moat, everything is dry (especially the firewood) and there is only one ordained way to get things done in the castle. Trying to change any single piece is a threat to the abstraction castle’s integrity and must be thwarted.
At the same time, the abstraction castle is not self-sufficient. It must depend on the surrounding landscape for all of its essential supplies. It pulls everything towards its centre and relies on the assumptions of its designers to not fail during a crisis.
Change is coming, change is the enemy, and the abstraction castle is impregnable. Either there’s a prolonged siege, during which the castle is forced to adapt to the change against its will, or the castle is just left alone entirely to sit in its moat while the change continues elsewhere.
An abstraction castle is the polar opposite of code that is easy to delete. For every advantage of code that is easy to delete, an abstration castle has the corresponding disadvantage:
| Easy to delete | Abstraction castle |
|---|---|
| “Make it easy to delete.” | “Make it hard to delete.” |
| “Keep it simple.” | “Make it elaborate.” |
| “Be self-sufficient.” | “Consume everything in the surroundings.” |
| “Make fewer assumptions about other areas.” | “Dominate the landscape for miles around.” |
The idea of an abstraction castle also ties in well with these jokes, which gain extra meanings in this context:
“All castles had one major weakness. The enemy used to get in through the gift shop.”
“Oblivious tourist: ‘Why did they build this castle right next to a noisy airport?’”
– clichéd joke about whatever group of tourists is unpopular at the time.
These feel relevant to the idea of abstraction castles because they vividly highlight how what was once supposed to be a permanent and undefeatable solution is made ridiculous when the context changes. And the context will always change, because it is out of our control.
One more quote, this one from the field of systemantics as described in The Systems Bible (which I love):
“The army is now fully prepared to fight the previous war.”
Again, this gets at the idea that predicting the future is difficult, so we should expend our limited resources cautiously when dealing with such uncertainty. Abstraction castles do the opposite of this – they try to expend the maximum amount of resources on building absolute certainty that they are correct and should be highly resistant to change (just like a physical castle).