How do you make things simple?
I’ve written that simplicity is powerful, and that it undergirds many deep architectural breakthroughs. In posts about pragmatism and balance, I’ve quoted Oliver Wendell Holmes about the simplicity on the other side of complexity.
But I’ve never talked about how to achieve it.
photo credit: hurley gurley (Flickr)
This is not an easy question; if we knew how to make things simple, we’d do it more often and more quickly. It takes some serious effort (and genius) to go from centuries of experiments and volumes of equations to e = mc2. I’ve been pondering simplicity in software architecture for a decade, and I’m certain I’ve only scratched the surface.
Still, simplicity is a learnable skill, and some strategies are consistently helpful…
1. Encapsulate
I put this one first, because it is straightforward and virtually guaranteed to pay off. This strategy isn’t a panacea, but it’s a good place to start.
When a problem is complicated, fence it off behind a disciplined interface, and then ask yourself what the problem looks like on the outside. This will provide useful constraints. Now peer inside your complicated inner world, and repeat the process. How can the problem be divided into pieces that are individually tractable, even if they have a lot of gory detail inside?
Recurse as needed.
2. Cut corners
In many, many cases, the complexity we wrestle with comes from an overly ambitious scope. Overbuilding is probably my greatest weakness as an architect; I’ve made the mistake way too often.
Perhaps you want to improve logging in your product. At first it seems simple, until you start asking how to localize your logs, and how to handle thousands of logged events per second, and how to silo your logs so one tenant can’t see what another tenant is doing.
One important way to simplify is to say: we’re not going to localize, and we don’t need to run fast when logging thousands of events per second, and we don’t need multitenant distinctions in our logs.
You can’t always get away with this sort of simplification, but it’s worth considering.
3. Hire a specialist
Do you do your own taxes, your own dentistry, and your own legal work? Why not?
This is a complement to the “cut corners” strategy. If you can’t make the tax code simpler, perhaps you can ignore the problem most of the time, and occasionally hire an accountant that reframes complexity to be more manageable. To continue the log example, maybe you write a script that gives each tenant a subset of the overall logs, on demand.
4. Delegate
Human beings realized long ago that even the smartest and most well rounded person in the world can’t run an entire organization alone. A CEO hires someone else to think about marketing, about sales, about engineering, about support, about facilities, about accounting.
Many software architectures are crushed by complexity because they have a CEO that’s trying to empty trash cans, pay the bills, woo customers, and keep the board happy, all at the same time. If your system has a centralized brain, and everything runs through it, consider putting some other brains to work. I have become convinced in the past decade that distributed architectures almost always beat centralized over the long haul, for this reason.
5. Change your metaphor
Suppose you have a workflow engine, and you’re struggling to make it more responsive. You normally model worflow as a state machine, because it gives you crispness and predictability.
Well, maybe you should stop thinking of your workflow engine as a state machine, and start thinking of it as a bureaucracy. What makes bureaucracies grind to a halt? How do you get around them? Bribes work wonders in some bureaucracies; should you allow high-priority items to “bribe” their way through for faster outcomes? What if an urgent task walks in the front door of the bureaucracy’s office and takes the Grand Poobah’s secretary hostage?
I think this strategy is underutilized in almost every long-running architecture. Metaphor can drive insight in ways we don’t talk about enough.
One other hint on this one: Do some reading about gossip protocols and bully algorithms some time. The richest sources of metaphor for me are human society (families, companies, social networks, politics, fraternities, multi-level marketing schemes, crime syndicates…) and life (cells, ecosystems, packs and herds, predators/prey, …). This is why I’m writing a whole book about what life can teach software architects. Subscribe to my blog for more news on this.
6. Ask a child
It doesn’t have to be someone young, really–the true requirement is that it needs to be someone with some intellectual distance from the problem, who’s able to ask probing questions. Children are just the perfect prototype.
Years ago, thieves were raiding high-end clothing stores. They’d run in, sweep all the hangers to the end of the rack, lift off an armful of expensive merchandise, and run out the door before anybody could stop them. Stores tried all kinds of things, but the thieves were organized and fast, and they kept escaping.
Finally someone suggested turning every other hanger top in an opposite direction. Half the hangers would lift off to the left, half to the right. Next time the thieves came in, they discovered that it was impossible to pull an armload of clothes off the rack quickly. Problem solved.
And then there’s the story of the factory that went to great lengths to prevent the 1-in-a-thousand box that exited the assembly line empty. They built xray machines to check the boxes, stationed someone to monitor the xray screen continuously… I bet they felt foolish when someone bought a cheap fan and simply blew the empty boxes off the conveyor belt…
7. ???
Undoubtedly, other helpful strategies can also contribute to simplicity. Like the ones I’ve listed above, they will probably have their limits. We are unlikely to discover a silver bullet–and even if we did, the arms race of our industry makes it probable that we’ll need a silver missile in the near future. It takes hard thinking, and hard work, to wrestle complexity into clean, reusable packages that fit together nicely. And it always will.
But–ah!–the beauty of well crafted minimalism…
Perhaps Leonardo da Vinci said it best: “Simplicity is the ultimate sophistication.”
Action Item
Identify a metaphor that’s important to your architecture. Find at least one other metaphor that you could use to replace it. Spend 5 minutes exploring the alternate metaphor. Do you see strengths, weaknesses, opportunities, and threats to your architecture in new ways?
Codecraft 
I like ask a child! Children can come up with the greatest of things! Thanks for sharing this awesome blog!
The other day my young nephew and his older brother were having a conversation.
Older brother: “What’s a baby dog called?”
Younger nephew: “A puppy.”
Older brother: “What’s a baby sheep called?”
Younger nephew: “A lamb.”
Older brother: “What’s a baby chicken called?”
Younger nephew: “A yolk!”
Funny. But also shows how kids have different perspectives that can break us out of the box. :-)
You hit the nail with a sledgehammer with this post!
Metaphor becomes more important every time I work with a new system that no one can explain. Usually the problem is that they don’t have a metaphor to relate it to. People work best with an abstraction in their heads.
And, I will add another vote for simplicity. As systems become more distributed and massive, communication becomes the problem. Funny how that mirrors the human problem when people work together. The answer is often simplicity. Think of the largest autonomous system out there – the internet. TCP/IP works with what might be the simplest solution to multiple machines trying to talk at the same time “wait a bit and try again”. I’m sure everyone can think of a much “better” solution. I am also sure it is more complicated, and I am resonable sure that it wouldn’t work as well.
My goal is: make it simple enough to understand and wrap that understanding in a memorable metaphor.
The internet is such a good example. Not only is TCP/IP amazingly simple (in concept, not necessarily in impl), but so is the HTTP protocol. It seems amazing to me that I ever lived without it. Thank you, Tim Berners-Lee and Roy Fielding and all the other smart people who achieved so much by simplifying so much!