Contribution 21

From WikiContent

Revision as of 06:18, 15 May 2008 by Kevlin (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Simplicity before generality, use before reuse

A common problem we find in frameworks, libraries and other infrastructure code is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples. So, this principle acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and quite likely) that the simpler solution will turn out to be the more general one. And if it doesn't, it will be easier to change the simpler solution to what you need than to change the general one that turns out not to be quite general enough in the right way.

Many things that are designed to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

Generality should equate to simplicity and simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, and pulls in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

Design is compromise, and all flexibility is a double-edged sword. Many people mistakenly see design decisions made in the name of flexibility as win-only situations, a narrowness that belies reality. If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many in software development value generality, people do not on the whole pay for (or need) it: they tend to have a specific situation, and it is the solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options and parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative designs.

By Kevlin Henney

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools