Abstraction. Encapsulation. Automation.
We have a lot of tools in our tool belt to handle complexity. Once complexity rears its head, either by enlightenment (“Holy crap, our publish process is 15 steps”) or something less gentle (“We forgot to do step 10 so the site crashed”), we’re told to handle it be wrapping it in some sort of facade. Hide it. Shield the trembling masses from its horror so that it shall not hurt another soul.
However, when complexity is hidden, all of the tacit knowledge that went into making it complex it also hidden. The intricate web of knowledge that went into the creation of the complexity is calcified in a series of steps, scripts or bizarre rituals. As time grows on, the connections to these pieces of knowledge grow fainter and fainter. People leave your company. You forget why you did something. Suddenly, when faced with having to explore the complexity, you’re in trouble. You no longer remember the reason for the this piece or that process.
“Because that’s what we’ve always done it!”
You’re lost in a sea of knobs and switches, unable to grasp what to do or where to go next. It doesn’t take long before you throw up your hands and decide on starting over. After all, this time, you’ll really do it right.
When you’re being poked at with the complexity stick, that pain should be your inclination to eliminate the complexity, not just hide it. Just as taking more and more pain killers won’t fix a physical pain, masking complexity will only push the pain off until the future. A future, by the way, where you’ll be less adept at handling the complexity and any issues that might arise.
What if instead of wrapping the complexity as a first step to coping, you looked to see if you could simplify it first? Simple is easier to work with than complex. It’s easier to comprehend. It’s easier to change. It’s easier to explain. Frequently, it’s also less fragile.
When you’re working you’re working in a collaborative environment, the creator of the complexity can’t always be relied on to provide on-demand explanations or fixes should something go wrong. We’ve all gotten that call about an emergency dealing with something we have no experience with, but are expected to fix anyway. Have you ever gotten in that situation and thought to yourself “Man, I wish this stuff was more complex.”
I haven’t either.
The kicker is that this stuff happens even on a team of one. Look back at something you’ve done a while ago. Code, an article, a half knit winter cap. Whatever. Do you always remember why you did something? Why you went a certain route? I don’t. Even after 10 years in the industry, I still utter the phrase “What the hell was I thinking here?” very, VERY often. If you can’t even instantly come up to speed on something complex you did, there’s very little hope of you just walking right in to something someone else set up and being able to work with it. It’s far more likely that you’ll spend a few moments gauging the “goodness” of what was done, decide you could have done it better and start in on redoing it. Thus the cycle begins anew.
Far better to follow a consistent mantra. Simple over Complex. Explicit over Implicit. Clear over Ambiguous. Straight Forward over Clever.
So the next time you’re faced with something complex, take a hard look at what you’re doing and why you’re doing it. Visit your assumptions. Do your existing assumptions still hold true? Are some of them based on old information? Can you remove some of the waste in what you’re doing?