Kernel Mustard

I can’t remember where I first heard the terms complexifiers and simplifiers, although it looks like they were originally coined in a blog post by Scott Berkun, but I’ve found them to be more and more useful in recent weeks.

My company is working on a Great New Service™ and we’re trying to finish up the first round of design. Virtually all of the intellectual energy I’m spending in these discussions is centered on factoring out complexity whenever possible.

Complexity is amazingly expensive:

• It’s obviously more expensive to code.
• It costs the business in terms of things like time-to-market.
• It takes (much) longer to test.
• You can wind up actually sacrificing the quality of the product you were trying to improve, by rushing the implementation process or short-changing QA (or, likely, both).
• It presents bigger attack surface.
• It makes security architecture harder.
• It is more prone to bugs.
• It makes individual bug fixes harder.
• It requires smarter/better/more experienced developers.
• It makes it very hard to replace those developers.
• It’s harder to communicate your marketing message to your audience.
• It can negatively impact scalability, performance, and responsiveness to demand changes.
• It can kill your ability to adapt your product to changing market conditions.

I have a rule related to this: a system’s overall design is limited to what the lead technical person can fit into her head. Once your system is too complex to fit between one person’s ears (at a sufficient level of detail), you have to start dividing the architecture and scaling the team in ways that have yet more expenses built in, in terms of design, management, and programmer interactions.

Put another way: You have a limited amount of complexity that can be spread across your product. Spend it carefully.

Simplification is difficult, because complexity is the default route of most bright people that I’ve met. It’s fun (and on a deeper level, very satisfying) to build complex things. That’s why simplification has to be a going-in design goal. When you re-state simplicity as a goal, the team’s creative talents can be applied to the problem of simplification, which makes everyone happy.

There are tons of examples of people battling with this question, ranging from this week’s Vista vs. OSX shutdown wars (more here and here and here) to more abstract designs like Networking Truth #12.

This point of view may be an oversimplification or you may already be years into a shipping product, with few chances to apply this principle. But if you’re in the design stage of a new product or service, like I am right now, do yourself a favor and (as my grandfather used to say) don’t make a Rembrandt!