Categories
Software Architect

Simplicity before generality, use before reuse

97 Things Every Software Architect Should Know – 18/97

A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

Favoring simplicity before generality 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 more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn’t turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the ‘general’ one that turns out not to be quite general enough in the right way.

Although well meant, many things that are designed just 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. Effective generality comes from understanding, and understanding leads to simplification. Generalization can allow us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development. They are based on assumptions that later turn out to be wrong, offer choices that later turn out not to be useful, and accumulate baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has 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 tricky configuration options, overburdened (not just overloaded) 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, simpler designs.

'Coz sharing is caring
Categories
Software Architect

Business Drives

97 Things Every Software Architect Should Know – 17/97

In the context of business enterprise application development, an Architect must act as a bridge between the business and technology communities of an organization, representing and protecting the interests of each party to the other, often mediating between the two, but allowing the business to drive. The business organization’s objectives and operating realities should be the light in which an Architect leads technology-oriented decision making.

Businesses routinely plan for and articulate a specific, desired Return on Investment (ROI) before undertaking a software development initiative. The Architect must understand the desired ROI, and by implication, the limits of the value of the software initiative to the business, so as to avoid making technology decisions that could cause the opportunity to be out-spent. ROI should serve as a major piece of objective context in the give-and-take conversations with the business about the value of a feature versus the cost of delivering that feature, and with the development team about technical design and implementation. For example, the Architect must be careful to represent the interests of the business to the development team by not agreeing to choose technology that has unacceptably costly licensing and support cost implications when the software is deployed into testing or production.

Part of the challenge of letting the business ?drive? is providing enough quality information about the ongoing software development effort back into the business to support good business decision making. That‘s where transparency becomes crucial. The Architect, in conjunction with development management, must create and nurture the means for regular, ongoing information feedback loops. This can be accomplished by a variety of lean software development techniques, such as big visible charts, continuous integration, and frequent releases of working software to the business starting early in the project.

Software development is fundamentally a design activity, in that it involves an ongoing process of decision making until the developed system goes into production. It is appropriate for software developers to make many decisions, but usually not to make business decisions. However, to the extent that the business community fails to fulfill its responsibility to provide direction, answer questions and make business decisions for the software development team, it is actually delegating the making of business decisions to software developers. The Architect must provide the macro-context for this ongoing series of micro-decisions made by developers, by communicating and protecting the software architecture and business objectives, and seek to ensure developers do not make business decisions. Technical decision making un-tethered to the commitments, expectations and realities of the business, as articulated by the business community on an ongoing basis, amounts to costly speculation and often results in an unjustifiable expenditure of scarce resource.

The long-term interests of the software development team are best served when business drives.

'Coz sharing is caring