Wednesday, March 31, 2010

On Simplicity

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

This applies to software design, project design, and software test. The more simple it can be and still solve the problem, the better off you are. If you can write a test with 16 steps to show a bug, or a test with 4 steps to show the same bug, go with the four-step test. If you can put together a project plan on the wiki you already use or you can go buy project management software and learn it, go for the wiki.

Make it easy. Make it work. That is simplicity.

When things stop working it's generally fairly obvious. Something will break, or in the case of human processes, something will start to feel wrong. Functionality is a prerequisite; if it has to be more complex to work, then it has to be more complex.

Once it works, though, making it as simple as possible is the goal. It's hard to do, and it's scary to decide to skip something or to not do something. But as long as it works, ask yourself if you can do it more easily or with fewer steps.

It's hard but possible to be simple enough to obviously work. Let's see how close we can get.


  1. Different people can have different ideas on what works means. It's obviously never going to be perfect for everyone, so when do you stop on the functionality vs complexity curve?

  2. Occam's razor: "pluralitas non est ponenda sine necessitate"

  3. well post here about software design. It's a very informative post.