## Complexity

I’ve noticed that I have a bias toward complexity. I tend to try to look at problems from all the angles I can think of. Most problems are complex from at least some points of view; otherwise, they would not be problems at all. Looking at problems from all angles encourages a focus on their complex aspects rather than their simple ones.

I do profoundly believe H.L. Mencken’s classic quote: “For every complex problem, there is a solution that is simple, neat, and wrong.” For any problem, it’s very tempting to shear away the complexity and push forward with a solution that solves the simpler part. Unfortunately solving the simpler part of the problem tends to make the complex part both worse and harder to solve later.

This is a common problem in programming. I think it is the primary reason that programs become harder to maintain over time. It is very hard to keep a focus on solving complex problems rather than ignoring the complexity in order to solve a simpler problem. This is also a common problem in politics, and I’m sure we can all find our favorite examples there.

At the same time, I’ve come to realize that focusing too much on complexity is a different and more subtle trap. It encourages you to focus on the specific issues rather than the general ones. Sometimes a complex problem can be solved by solving a different, larger, problem. Sometimes you need to take a step back. The trick is to not ignore the complexity, but to be open to the possibility that it simple doesn’t matter.

When I was younger, I always felt that Alexander cheated when he simply cut the Gordian Knot. He didn’t actually solve the problem, and indeed I think the analogy is often used poorly, to suggest that it’s somehow smarter to not solve the problem. However, I’ve slowly come to realize that there is a good use of the analogy. I don’t know whether Alexander’s solution was a good one; he didn’t live long enough to prove it one way or another. But there are times when that is the right approach.

I apologize for the abstract nature of this post. I’ve been thinking of this in the context of working on Go. I think that working on the project has helped me a lot in terms of looking for the larger simplicity without ignoring the real complexity.

## Samuel Tardieu said,

November 18, 2010 @ 11:40 am

Your post reminded me of Chuck Moore’s 1x Forth:

“Simplify the problem you’ve got or rather don’t complexify it. I’ve done it myself, it’s fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you’ve got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.”

(from http://www.ultratechnology.com/1xforth.htm)