Use uncertainty as a Driver

?

Use uncertainty as a Driver

Kevlin Henney

Confronted with both OpTionS, most people think, and the most impor-tant thing to do a choice between them. In design (software or otherwise), it's not. The presence of the options is a indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to Deter-mine where can defer commitment to details and where you can partition and a Bstract to reduce the significance of design decisions. If you hardwire The first thing this comes to mind and you ' re more likely to be stuck with it, so that incidental decisions B Ecome 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 isn't all design is architecture. Architecture represents the significant design decisions that shape a system, where significant was measured by cost of cha Nge. " What follows from the effective architecture is one generally reduces the significance of design decision S. An ineffective architecture would amplify significance.
When a design decision can reasonably go one of the ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How does I design so" the choice between A D B is less significant? " The most interesting thing isn't actually the choice between A and B, but the fact that there is a choice between A and B (and that the appro-priate choice are not necessarily obvious or stable).
??? Things every software Architect should Know
?
?? An architect could need to go in circles before becoming dizzy and recogniz-ing the dichotomy. Standing at a whiteboard (energetically) debating options with a colleague? Umming and ahhing in front of some code, deadlocked through whether to try one implementation or another? When a new requirement or a clarification of a requirement have cast doubt on the wisdom of a current implementation, that ' S uncertainty. Respond by figuring out who separation or encapsulation would isolate that decision from the code that ultimately depends On it. Without this sensibility the alternative response are often ram-bling 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 are taken at speed and without looking Back.
There is often pressure to make a decision for the decision ' s sake. This is the where options thinking can help. Where There is uncertainty over different paths a system's development might take, make the decision don't to make a decisio N. Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late tha T it is not possible to take advantage of this knowledge.
Architecture and process are interwoven, which was a key reason that archi-tects should favor development lifecycles and a Rchitectural approaches that is empirical and elicit feedback, using uncertainty constructively to divide up both the Sys TEM and the schedule.

Use uncertainty as a Driver