Ceiling of Complexity

Dan Sullivan coined an interesting term: The Ceiling of Complexity™. (Sullivan has a habit of trademarking™ everything™ he™ says™. I dislike the gratuitous trademarking, but I like the phrase “ceiling of complexity.”)

The idea behind ceiling of complexity is that every project you complete creates residual responsibilities and expectations. This residual may be small, maybe not even noticeable, but it’s always there. Over time, this residue builds up and adds complexity. Eventually it forms a ceiling and limits further progress until you do something to break through the ceiling and reach a new state of simplicity. The ceiling of complexity is a byproduct of success.

Sullivan’s picture of a ceiling of complexity is sort of existential crisis, something an individual would only face a few times over a career, but I find it useful to use the term for less dramatic situations. It gives a way to talk about the gradual accumulation of small responsibilities that become significant in aggregate.

The idea of a ceiling of complexity can be applied to projects as well as to careers. For example, the entropy of a software code base increases over time. Successful projects may have a faster increase in entropy. The software has to maintain backward compatibility because many people depend on its features. Sometimes even its bugs have to be preserved because people rely on them. It’s much easier to renovate software that nobody uses.

Related posts:

The dark side of linchpins
Abandoning projects
A little simplicity goes a long way

4 thoughts on “Ceiling of Complexity

  1. “Sometimes even its bugs have to be preserved because people rely on them.”

    The canonical example of this should probably be make, with its reliance on hard tabs instead of generic whitespace. According to Stuart Feldman this bad decision was locked in forever after only a few weeks and a user base of dozens of his friends!

  2. Make is a great example, especially when you look at the ratio of the consequent pain to the size of the decision. You could argue that it was a bad design choice and not a bug, but it has the same feel as a bug everyone knows to work around.

    Another example is JavaScript. It would have been a much better language if it could have had one revision before becoming a de facto standard.

  3. Windows sounds like the perfect example of this. There are bugs they’ve had to preserve since Windows 95 because so much software has been written that depends on it. It didn’t help that certain versions of Visual Studio listed these bugs as features that you could use. From what I understand so many graphics drivers fiddled with the graphics settings interface they’ve had to put in a dummy version for them to screw around with in modern versions, or the old drivers wouldn’t work.

  4. Oh, no, make is easy. But sendmail.cf, now, that’s the picture in the dictionary next to “compexity”. It’s such a complex mess that the author actually believed using the m4 macro processor would improve things.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>