“…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.”
– Peter Kay
“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.”
– The Systems Bbible, p.31
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).
View post:
Abstraction castles
|