There are two misleading ideas (espoused theories) about how architects and designers make decisions.
According to classical decision theory (Herbert Simon), one or more designers develops a series of alternative options, working collaboratively or in competition, and then the design team or the client selects the one that best fits the requirements. This approach may not yield a perfect solution (optimizing) but hopefully produces a good enough solution (satisficing).
Although this approach is used in some design fields, it is unusual in the enterprise space for a designer or design team to produce more than one solution. In the event that the first option is not good enough, the design protocol allows for something called iteration, which seems to repeat certain design steps until a good enough solution is produced.
But in this context the word iteration is misleading. In computer science, the word simply means repeating an action until some condition is met. It is not always possible to determine in advance whether a given iteration will ever terminate - this is known as the Halting Problem.
In design, however, the word iteration seems to refer to something more like backtracking - undoing or discarding some work and trying something different. Designers are generally not taught to backtrack properly. Instead, they learn to avoid backtracking at all costs, and the little backtracking loop on the design protocol comes to be regarded as a safety feature one hopes never to use. (Unless you can blame someone else for changing the requirements or constraints.)
Furthermore, backtracking is popularly seen as a sign of design inexperience or incompetence, and designers who fail to produce a good enough design at the first attempt may try to conceal this fact. Consequently any backtracking that does occur tends to lack visibility and transparency, and hardly any useful learning takes place.
This suppression of backtracking may be one of the reasons why we are surrounded by designs and architectures that aren't very good.
See also Meaning of Iteration (Sept 2012)
No comments:
Post a Comment