Stories about Software


Annihilating Complexity

I think that I’ve been blogging long enough to earn a bit of latitude when it comes to making up pseudo-scientific ‘theories’ to describe the universe.  So, indulge me, if you will, as I abuse concepts of physics by using them as staging points for a narrative of human behavior.  I think it’ll be fun for all involved and it’s my hope that, on the other side of this, I’ve advanced the course of human knowledge rather than lowering everyone’s IQ.  But, hey, caveat emptor.

If you ever had the good fortune to take a high school chemistry class, you might have studied endothermic and exothermic reactions.  I say good fortune because these reactions involve the flow of heat into and out of systems, so appropriate demonstrations almost certainly involved melting things or blowing things up.  To (over) simplify the situation and avoid you needing to precisely define “system” or to ask the question, “what on Earth is enthalpy,” let’s just say that exothermic things spew heat into the world and endothermic ones remove it from the world.  Like I said, indulge me.

In a talk called, “Simple Made Easy,” Rich Hickey describes “finding” a term for the introduction of needless complexity to a system: “to complect”  (literally meaning to join together by weaving).  I’ve come to think of and use this word to describe times where a solution to a problem is actually more complicated than the problem itself, meaning there has been a pointless introduction of additional complexity.  Now that I spend my days in the world of Java again, I’m reminded of the witticism: “I had a problem and I used Java to solve it — now I have a ProblemFactory.”

Now, to bring this apparent non sequitur to heel, here’s what these two concepts have in common in my mind.  I’d like to define two camps of people: “endocomplectic” people and “exocomplectic” people or, “endocomplectics and exocomplectics.”  Endocomplectics are people who remove complexity from their surroundings — something about their nature allows them to simplify things, essentially absorbing, or at least deflecting complexity and making the area around them simpler for others.  Exocomplectics, on the other hand, add complexity to their surroundings, and make life harder for those nearby.

To get a bit more specific, let’s define three conceptual scopes: the world, the group, and the individual. The world is, well, the world. The group is the setting in which you can observe this in action — typically your team room or something similar in a work capacity (though it can also certainly apply to non-work considerations like families or groups of friends). And the individual is, not surprisingly, the person in question. Let’s also further divide the exocomplectics and endocomplectics into sub-categories. Exocomplectics include complexity creators and complexity adders and endocompletics include complexity removers and complexity annihilators. I’m operating on a hypothesis that this is the essence of what you need to seek or skip in interviewing and that any behavior from being a good teammate and human being to solving problems effectively can be expressed on this spectrum.  Crappy people create complexity and awesome people annihilate it.

Complexity Creators

I’ve actually posted about this, albeit many moons ago. A complexity creator, in the world/group/individual scoping sense, is someone who has some kind of internal reservoir of “potential complexity” and, like an octopus with its ink, spews it out into the world around them, seeking to obfuscate and confuse.


Think of someone you can recall that’s perhaps out of their depth in their role or else extremely lazy or something like that. You can probably picture someone that meets this definition and the weird things that they say when you ask simple questions like, “so, what did you do last week,” or “hey, can you work on feature X a bit?” Explanations as to how incredibly hard the task is start to rain down in an onslaught of excuse-hail, bludgeoning you into taking cover. “Oh, well, there’s a lot of angles, and I had to read up on it a bit and then consult Bill and Steve over in accounting, and then I fired off 12 emails to Microsoft, and…” You stand there, jaw hanging slack, because all they would have needed to do would have been to add a few lines of markup and call it a day.

This is a complexity creator. Complexity creators are exocomplectics that actually birth complexity into existence, adding opacity and disorientation to what otherwise would have been a clear cut situation. These tend to be net-negative producers whose removal from their group would be a classic case of “addition by subtraction.”

Complexity Adders

Complexity adders don’t manufacture any complexity themselves, but they do find a way to add it to the group. If you think of complexity as a sort of commodity, complexity adders move it from the world scope into the group scope. Generally, this is done without any ill-intent whatsoever and is primarily an accident. Perhaps the easiest example to understand would be a new Director of Software Development coming into a shop, sizing up the team, and introducing some kind of development process with all sorts of gates, phase exits, orchestration components and other elaborate things designed to solve problems that the team may face someday. New director is bringing a complicated ‘solution’ with him from the outside world and introducing it to the team. Usually this sort of thing doesn’t go particularly well.

Zooming out a bit, complexity adders are those who attempt good faith solutions but inadvertently muddy the waters. In their wake, they tend to leave a fair bit of confusion. There’s also an unfortunate insidious element to this type of team member in that their effort is often unimpeachable. That is, they really believe in what they’re doing and will often put in 70 hour weeks to try to see it through. Complexity creators generate and inject complexity to hide shortcomings whereas complexity adders suffer simply from bungled execution.

Complexity Removers

These folks are probably people you think of as classic good teammates. They have a tendency to cut to the core of issues and eliminate a lot of nonsense. Pragmatic solutions that make people’s lives easier are their bread and butter. If you’ve got too much on your plate and you’re stressed out, they’ll suggest that you punt some of it over to another group. If a BA or external stakeholder comes over with garbled requirements, a complexity remover will put the brakes on and insist on better input.

Complexity removers move complexity from within the group to somewhere else. As far as the group is concerned, they’re eliminating complexity and, since the world consists of lots of nested groups, they’re often improving things on the whole by shuffling it to where it belongs. Complexity removers are people that you’ll tend to remember fondly in some capacity or another as you go on about your career.

Complexity Annihilators

These people are game changers. Complexity removers do what they do via tweaks and incremental improvements, whereas complexity annihilators do something different. The former look for simpler ways to execute the existing solutions they have to the problem whereas the latter simply define different solutions. To put a little bit more concreteness to this, consider a scenario where a team was struggling to implement a web app that kept track of todo items and let you mark them as “in progress” or “finished.” A complexity remover might suggest first putting out a version that was just a single list and then implementing states later. Or, perhaps she would advocate using a client side javascript framework instead of struggling with the home-rolled version the team was using.

But a complexity annihilator would say something like, “dude, why don’t you just use Trello? Here, I’ll show you.” And, as the look of disbelief settles over the other team members, all present can sense the complexity just winking out of existence. Poof — gone! Now that we’ve solved that, what’s next?!

This is a pretty contrived example, but it illustrates the point — the game change. Complexity annihilators find ways to radically simplify the lives of those around them and without moving complexity anywhere. They just, well, annihilate it. And they’re good at it. I mention this last bit because someone who fails at this and oversimplifies into the realm of wrong or absurd (e.g. suggesting Trello as a solution for automated grammar corrections) is actually a complexity adder, by virtue of bringing some new, irrelevant idea into the mix.

So What?

As I mentioned earlier, I have an operating hypothesis that you can classify people along this spectrum pretty widely. I’ve talked exclusively about technical problems, by way of example, but think even of interpersonal relationships. Humans and their interactions are complicated, and it’s pretty easy to do something wrong and inadvertently annoy others or create destructive tension, which is a complexity-add (since tension represents a source of impediments). Complexity creators and adders in this context will tend to foment strife, deliberately or inadvertently. Complexity removers will diffuse situations and annihilators will invent ways to make said tension impossible (e.g. preventing arguments over coding standards by implementing an auto-format on the build machine).

This idea hasn’t percolated enough in my head for me to suggest interviewing tactics to elicit complexity adders, so I’d be open to suggestions. But, if we could come up with some, I think that it could shift the focus to something more productive than trying to figure out if people had X years of C# or whatever. And, as individuals, I think we could all do well to evaluate ourselves along this spectrum. I don’t think any of us are born into one of these buckets, per se, so improvement is certainly possible. It seems a worthy goal to me that we should all strive to be complexity annihilators.

newest oldest most voted
Notify of
Helton Moraes
From the Zen of Python: “Complex is better than complicated.” I believe the real Evil Thing is not complexity per se, but complication. A system is complicated when it is more complex than it need to be. I have read somewhere that “[in systems design] any unidentified complexity is a recipe for disaster”, and I agree with that, because a system that is LESS complex that it needs to be is usually a dysfuctional system. So my point is: complex is not necessarily bad, and complexity is not an automatic symptom of “wrong” or “dysfunctional”. But complication is always bad.… Read more »
Erik Dietrich
It sounds to me as though that author quasi-co-opted words to make a point. http://english.stackexchange.com/questions/10459/what-is-the-difference-between-complicated-and-complex This link is interesting. Your reference draws a mention, but there are several other varying stabs at drawing a distinction between these two terms: extrinsic versus intrinsic, quantitative versus qualitative, bad vs neutral (in the Zen of Python case). All of them seem to be axiomatic, though. Complex is bad and complicated is okay because I define complex to be bad and complicated to be okay for the purpose of whatever I’m about to say next. (It’s the “given” in the given-when-then)
Geoff Mazeroff
I agree with Helton’s definition: complicated > complex. Although I don’t have the breadth of experience working with other developers/companies as you and your readers do, I’ve learned that humans are “messy.” We don’t always think logically, we have biases, and we let egos/politics play into things. Engineers love to build things, and sometimes when given the opportunity, try to apply all of the Gang of Four patterns to a simple app. Eric, what influence would you say the work environment has on this spectrum? Maybe there’s a developer who learned early on (through bad mentors/leadership) that looking busy (read… Read more »
Erik Dietrich
Oh, there’s no doubt that the environment can have an intense and damaging effect on people along these lines. I’ve encountered no shortage of people for whom such obfuscation is a desperate means of self-preservation. Far and away the most common incarnation of this, in my experience, is when people are put in a position of being held responsible for outcomes over which they have no control. One of the most fertile places for this is the software project manager that sits in corporate status meetings and gets berated for overages. PM can’t actually write software and if they’re not… Read more »
Minnesota Steve

I’ve heard something like this before. Something along the lines of:

The Junior Developer solves easy problems with complex solutions.
The Senior Developer solves complex problems with complex solutions.
The Expert Developer solves complex problems with simple solutions.

Erik Dietrich
It’s an appealing aphorism, and I think there’s certainly truth there. It reminds me of the wisdom of a good software consultant advising clients in some cases that the best solution to their problem is to tweak their process and not spend any money writing software. Observing developers, it does seem to take a while before the solution to every problem is, “I know, I’ll write an app that…” even when the “that” is an inferior version of ubiquitous software or something that makes no sense. I wrote once about watching out for “mindless automation” and I think it takes… Read more »
Amitai Schlair
This classification rings bells for me. I’ve worked with Creators and Adders, for sure, and I like to think of myself as a net Remover (so I’ll go to a lot of effort to have that effect). But I don’t believe Annihilators exist, because I don’t believe complexity can be annihilated, because I believe every decision is always a tradeoff. For instance, I recently switched from a personal todo list that satisfied some nerdier needs (vi, Markdown, git, work offline, dogfood an open source project I co-lead, own my data and control my service) to a personal todo list that… Read more »
Erik Dietrich
Accidental and essential complexity is (by my snap-understanding) what Helton and the Zen of Python seem to drive at. I didn’t really address (and didn’t seek to) the notion that there is unavoidable complexity intrinsic to a task (essential complexity, as I understand the term) and then the added complexity/complication that we bungle into it. I accept that premise, certainly. No matter how efficiently you plan it, there is simply some complexity associated with a task like alphabetizing a list. Short of some kind of metaphysical intervention, a non-trivial effort is required to move from unsorted to sorted. But here’s… Read more »
Amitai Schlair

If a Complexity Annihilator is someone who seeks (and often provides) insightful, actionable answers to the question “Can we avoid that entirely?”, then I (1) agree they exist and are very special, and (2) am always trying to be one. Applied laziness. 🙂

Anthony Ruffino
There are abstract frameworks that I have implemented for various projects at work. Occasionally, they are never used more than once, and the complexity of abstraction might be a wasted effort. For every time that happens however, there are usually two other examples where the team gets to reuse a framework several times over and any time wasted on other unused complexities in the other instance is validated: At least in terms of whether or not the practice is economical to apply without question. That being said, I do ask myself each time if a framework is needed and I… Read more »