Dimensions Of Simplicity

When you are told to DoTheSimplestThingThatCouldPossiblyWork, you might ask "WhatIsSimplest?" The simple answer is do whatever you find simplest.

Here's a less simple answer. Simplicity comes in many dimensions:

 1) Codability  - how quickly you could code it
                  "The less you change, the less new stuff there is to understand"
 2) Compactness - how few lines of code it would take
 3) Elegance    - how well an implementation would get to the essence
 4) Familiarity - how many people would likely understand the implementation
                  "It's simple because it's a standard binary tree."
 5) Legacy      - how well solution leverages existing tools
                  "It's simple because we don't have to do much work."
 6) Obviousness - how quickly you think of the idea/algorithm
                  "It's simple because it's the first thing I came up with that works."
                  another important factor: how likely is it that someone else would come
                  up with the same solution
 7) Readability - how quickly you can understand it the next day (or other people).
                  "It's simple because I can figure it out at a glance."

When you evaluate possible solutions, you need to decide which dimensions of simplicity matter the most for your project.

You also need to evaluate whether utter simplicity is worth the complex undertaking you will be compelled to if you seek it. And in the interest of keeping this page (relatively) simple, we explore the ParadoxOfDimensionsOfSimplicity elsewhere...

---

Main benefits:

Codability:

• gets you finished with code most quickly

Compactness:

• KeepMassLow

Elegance:

• code that gets to the "essence" tends not to have wasted parts
• see ElegantSimplicity

Familiary:

• least likely to raise red flags
• often plays into extract-common-method refactoring

Legacy:

• don't reinvent the wheel, just retread it

Obviousness:

• gets you started the most quickly

Readability:

• easiest to understand

---

Shortcomings/strategies: Codability:

• Objection: May leave the code with a fall in simplicity on other dimensions
• Counter: Refactor to increase other dimensions of simplicity

Elegance:

• Objection: Elegant solutions can be overly clever.
• Counter: Make sure unit tests appeal to familiarity over elegance.
• Objection: Striving for elegance can turn into perfectionism and the coding equivalent of AnalysisParalysis.
• Counter: Create culture where elegance emerges from refactoring.

Familiarity:

• Objection: Can lead to whole team dumbing down to manager who last coded in COBOL 68
• Counter: Hire new manager who has worked with Fortran77.

Legacy:

• Objection: External dependencies can tie your hands down the road.
• Counter: If we change our minds later, we can always write a custom tool to replace the externally maintained tool. The "do lots of extra work to build a custom tool ourselves" option is always open -- even after we've demonstrated that there is no need. ;->

??? I don't think there's a universal counter, it really depends on a lot of things (Do we own it? Can we make changes economically? Is it up to the job?)

Obviousness:

• Objection: If it's obvious, it must be too simple.
• Counter: Make sure unit tests examine strange conditions.

Compactness:

• Objection: Striving for compactness can lead to obfuscation.
• Counter: Revert to a more common, simple way.

Readability:

• Objection: This can lead to overly long names and such.
• Counter: Very long names are as unreadable as very short names. Shorten them.
• Counter: Learn to double-click to select a word and copy it so you don't have to retype it each time. This is a good practice generally anyways to avoid typos.
• Counter: If you have IntelliSense, who cares?

---

CategorySimplification