The inherent value of simplicity

"Make everything as simple as possible, but not simpler." -- Albert Einstein

Simplicity: the lowest energy state of being; seen as beautiful or hurled as invective. Is it good or is it bad? In software engineering, the pursuit that engages all Knowledge Warriors in some fashion, simplicity is good, an attribute worthy of careful craft. Why? Because simplicity is efficient. Because simplicity is understandable. Because simplicity is challenging. Because simplicity is differentiated in the face of our complexity addicted culture. Consider that designing a piece of software with a single unnecessary feature requires 1 unit of design, 1 unit of build, 1 unit of testing, 1 unit of documentation, and 1 unit of maintenance. 5 units of effort are expended where 5 units could have been saved for expanding the boundaries.

"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." -- Antoine de Saint-Exupéry

Why strive for a simpler solution? To enumerate a few of the most obvious reasons:

• Ease of explanation
  
• Openness for future expansion/maintenance
  
• Performance
  
• Reliability – fewer bugs
  
• Upgradability – fewer rules means less opportunity for failure in upgrade
  
• Testing needs reduced
  
• Usability improved
  
• Training time reduced
  
• Development time reduced
  

A simple design requires that we pare away unnecessary features. There are three types of unnecessary features constantly on my radar. Recognizing them is the first step in elimination.

1. Bells and Whistles: Great for sales and terrible for maintenance, this class of unnecessary feature is usually an addendum to a feature considered critical to a particular business function. They blur the line between needful and wasteful. Bells and whistles seem attractive in the abstract, but in-practice are rarely used and frequently broken. A Bell and Whistle here and there can add spice to the application for an end-user, but each will carry costs in performance and maintainability. Use them to please, but please sparingly—the delivery of solid, dependable business tools should be our primary focus.
   
2. Belt and Suspenders: A belt will hold up your pants 99.99% of the time, only spend money on suspenders when 0.01% will result in loss of life or limb. Belt and Suspenders are unnecessary features that address unfounded fears of failure in an application—paranoia expressed in design. Graceful handling of foreseeable errors and exceptions is important, but keep in mind that features added to handle imaginary errors are likely to become the source of errors themselves. A single, general purpose, pragmatic approach to dealing with system failure is best. More specific errors will emerge through testing and early production use—these will emerge from the quirks of each enterprises environment. Save time and money to fix these specific, actual errors in quick-response fixes post-rollout rather than waste ten-fold the time imaging and addressing all manner of potential problems whose multitude are unlikely to occur at all.
   
3. Better mousetrap: The third class of unnecessary feature is often the brainchild of a business expert. These are paths of processing that add competitive approaches to well-established processes that will also be incorporated into the application—multiple paths that reach the same business outcome. The challenge in recognizing and redacting these better mousetrap features is to determine which of two processing paths represents the most acceptable to the mainstream business. End-users are often confused by multiple options whose outcomes are equivalent. When two such paths exist an individual will often pick a path based on their own internal criteria and then favor that path forever after. A single, straight-forward path to fulfilling a crucial business need will instead be leveraged consistently within the user community. Multiple paths are more likely to complicate training, introduce the possibility of inconsistent processes, and result in the inevitable introduction of maintenance headaches.
   

   "Remember that there is no code faster than no code." -- Taligent's Guide to Designing Programs