Wow. Stripped-down, reading-ready summary follows below, but here's the original link:
https://twitter.com/sarahmei/status/783340259073335296
The author, Sarah Mei (@sarahmei) has also registered liveablecode.com (no content yet).
[begin summary]
Sarah Mei
@sarahmei
Software dev, founder of @railsbridge, Director of Ruby Central, Chief Consultant of @devmyndsoftware. She/her. IM IN UR BASE TEACHIN U HOW TO REFACTOR UR CODE
I just figured out what I've been trying to say about code for like the last 20 years. My whole life just clicked into focus. #woah
If this was a disney movie, I'd definitely be singing & dancing rn
Also I bought the domain name, so you know it's serious
Ever been to a staged house? Like they're selling it, or it's the model for a set of houses they're going to build.
They hire interior designers to put furniture, rugs, etc. into the space, so people can imagine themselves there, and it's not just empty.
Staged houses are beautiful. They're designed to make you go "WOW" when you walk in, and think, "I could live like this."
But you can't actually live in a staged house. They leave out lots of things that make a space more cluttered, but also make it work.
Like the pot rack you need in the kitchen because there aren't enough cabinets, or the over-door towel rack in the too-small bathroom.
In real life you need a plunger near the toilet, remotes on the couch, & shelves for books that are for reading, instead of for looking at.
We need a certain amount of clutter to have an enjoyable house, and to feel relaxed when we're at home.
On the other side, we can't live easily in a house that is so overrun with clutter and stuff that it's mostly unusable. This is hoarding.
Most of our codebases are hoarded. But most of our object-oriented advice is a staged house. What we need is something in the middle.
If you watch the show Hoarders you'll notice that almost all the houses they clean out contain huge piles of "simple living"-type magazines.
It's not that these folks don't want to be clean - they love to look at these staged, organized homes. But they don't know how to get there.
Every office has shelves (or dropbox folders) full of software design books. We love to imagine living in these beautiful, simple places.
But in reality, both the staged house and the example codebase are unattainable in real life, and even if attained, unlivable.
What you want, in both cases, is something in the middle: enough clutter to be comfortable, with enough space to be flexible.
This brings us back to konmari, that we were talking about last night - an approach to deciding if you want a physical thing in your space.
Konmari boils all the calculus about keeping or donating a thing down to one question: does this item bring me joy?
It's powerful because it aligns our near-term actions (keep or donate the thing) with our long-term goals (be happier in our living space).
I have too much stuff. Konmari has helped me move towards that place where I have both enough clutter AND enough space to be comfortable.
Konmari has helped me move towards the ideal: a livable house.
And all konmari does is change the question I ask about stuff - away from "should I keep it?" and towards "how does it make me feel?"
Last night we talked about finding equivalent question for code that we can ask, to help us move towards a livable codebase.
We don't see livable codebases in books. We see staged codebases. We don't really know what we're moving towards, and that's ok.
We don't see livable house in the magazines, either. Clutter is personal. That's why they remove it from staged homes.
Everyone's livable house looks different. Clutter in a staged home always looks like someone else's mess.
But that's ok. Konmari works for lots of people because it's not prescriptive about what the end state is. It just gives you tactics.
We need that for code. We need a question we can ask that isn't prescriptive about the end state, but moves us in the right direction.
Instead of "does this bring me joy?" as in konmari, I think the right question for code is "do I understand this?"
Understand at many different levels: certainly including the surface level (what the code does), and also where it fits in the application.
Do I understand why this is here? Can I tell what problem it's solving?
If not - there are two possibilities for why. First, the code could be overly cluttered such that the purpose is obscured (a hoarded house).
Alternatively, it could be overly abstracted such that the purpose is hidden (a staged house).
We want the middle. We want livable code. Livable code starts & ends with understanding.
That's why the software design books can't show it to you -- understanding is personal. It depends on who's on your team.
A highly abstracted codebase is livable for a team of senior devs, but if you want to hire juniors, you're screwed. They can't live there.
Livable Code is what we strive for on every team. And it explains so much about how codebases relate to the teams who write them. Examples:
Why is it that a design decision can be appropriate in one codebase, but not in another, very similar one?
Because the people who will live with that design are different.
Why does the right set of abstractions shift over time, even on a single codebase, with a steady team?
Because the people living with that codebase are evolving and learning as time goes on.