Don’t make a Rembrandt
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!
December 19th, 2006 at 8:04 pm
[…] Steve Dispensa wrote a really good post about complexity in software design. Many of the points he raises are things we are continually reminding ourselves as we push forward with Teqlo development, and invariably face the reality that things can get complex really quickly if you don’t actively work to make them simplified. In almost every dimension, it’s much more difficult to create a simple system than a complex one because complexity is a virus that is self replicating. Kernel Mustard » Blog Archive » Don’t make a Rembrandt: […]
January 8th, 2007 at 9:45 am
[…] The more complex the system, the harder it is to secure. Apple’s Mac OSX has had a capability called FileVault for a while now. The basic idea is that it encrypts your home directory and everything that lives in it, including mail, browser cache, private application state, and so on. It’d be the windows equivalent of encrypting HKEY_CURRENT_USER plus all the files in your user’s directory. […]
June 14th, 2007 at 11:41 am
hi all.