Contribution 28

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (07:25, 13 July 2008) (edit) (undo)
 
(9 intermediate revisions not shown.)
Line 1: Line 1:
== Use uncertainty as a driver ==
== Use uncertainty as a driver ==
-
People usally think that the most important thing about the presence of two options is making a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can reduce the significance of design decisions. If you hardwire the first thing that comes to mind, you're more likely to be stuck with it so that incidental decisions become significant and the softness of the software is hardened.
+
Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind you're more likely to be stuck with it, so that incidental decisions become significant and the softness of the software is reduced.
-
There are many definitions of architecture. One of the simplest and most constructive comes from Grady Booch: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." What follows from this is that an effective architecture is one that generally reduces the significance of design decisions. A system may be subject to frequent change, with certain design decisions being revisited. Of itself this need not be a problem, but it becomes a problem if redesigning involves significant rather than under-the-radar changes. Without paying close attention to the partitioning, incidental decisions that should be minor can escalate into architectural decisions that are difficult to change.
+
One of the simplest and most constructive definitions of architecture comes from [http://www.booch.com/architecture/blog.jsp?archive=2006-03.html Grady Booch]: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." What follows from this is that an effective architecture is one that generally reduces the significance of design decisions. An ineffective architecture will amplify significance.
-
Uncertainty and change can amplify the significance of design decisions. When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How do I design so that the choice between A and B is less significant?" The most interesting thing is not the actual choice between A and B, but the fact that there is a choice between A and B and that the correct choice is not immediately apparent.
+
When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How do I design so that the choice between A and B is less significant?" The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B (and that the appropriate choice is not necessarily obvious or stable).
-
Undertainty is not always immediately obvious. Sometimes an architect needs to go in circles before becoming dizzy and recognizing the dichotomy. Standing at whiteboard (energetically) debating options with a colleague? Umming and ahhing in front of some code, deadlocked over whether to try one implementation or another? When a new requirement or a clarification of a requirement has cast doubt on the wisdom of a current implementation,that's uncertainty.
+
An architect may need to go in circles before becoming dizzy and recognizing the dichotomy. Standing at whiteboard (energetically) debating options with a colleague? Umming and ahhing in front of some code, deadlocked over whether to try one implementation or another? When a new requirement or a clarification of a requirement has cast doubt on the wisdom of a current implementation, that's uncertainty. Respond by figuring out what separation or encapsulation would isolate that decision from the code that ultimately depends on it. Without this sensibility the alternative response is often rambling code that, like a nervous interviewee, babbles away trying to compensate for uncertainty with a multitude of speculative and general options. Or, where a response is made with arbitrary but unjustified confidence, a wrong turn is taken at speed and without looking back.
-
When faced with uncertainty, use that as a driver in design. Take a step back and figure out what separation or encapsulation would isolate that decision from the code that ultimately depends on it?
+
There is often pressure to make a decision for decision's sake. This is where options thinking can help. Where there is uncertainty over different paths a system's development might take, make the decision not to make a decision. Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late that it is not possible to take advantage of the knowledge.
 +
 
 +
Architecture and process are interwoven, which is a key reason that architects should favor development lifecycles and architectural approaches that are empirical and elicit feedback, using uncertainty constructively to divide up both the system and the schedule.
By [[Kevlin Henney]]
By [[Kevlin Henney]]
 +
 +
(Edited RMH 2008-05-28, re-edited KH 2008-07-02, edited-again 2008-07-12)
This work is licensed under a
This work is licensed under a

Current revision

Use uncertainty as a driver

Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind you're more likely to be stuck with it, so that incidental decisions become significant and the softness of the software is reduced.

One of the simplest and most constructive definitions of architecture comes from Grady Booch: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." What follows from this is that an effective architecture is one that generally reduces the significance of design decisions. An ineffective architecture will amplify significance.

When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How do I design so that the choice between A and B is less significant?" The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B (and that the appropriate choice is not necessarily obvious or stable).

An architect may need to go in circles before becoming dizzy and recognizing the dichotomy. Standing at whiteboard (energetically) debating options with a colleague? Umming and ahhing in front of some code, deadlocked over whether to try one implementation or another? When a new requirement or a clarification of a requirement has cast doubt on the wisdom of a current implementation, that's uncertainty. Respond by figuring out what separation or encapsulation would isolate that decision from the code that ultimately depends on it. Without this sensibility the alternative response is often rambling code that, like a nervous interviewee, babbles away trying to compensate for uncertainty with a multitude of speculative and general options. Or, where a response is made with arbitrary but unjustified confidence, a wrong turn is taken at speed and without looking back.

There is often pressure to make a decision for decision's sake. This is where options thinking can help. Where there is uncertainty over different paths a system's development might take, make the decision not to make a decision. Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late that it is not possible to take advantage of the knowledge.

Architecture and process are interwoven, which is a key reason that architects should favor development lifecycles and architectural approaches that are empirical and elicit feedback, using uncertainty constructively to divide up both the system and the schedule.


By Kevlin Henney

(Edited RMH 2008-05-28, re-edited KH 2008-07-02, edited-again 2008-07-12)

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools