How to count mistakes
When we examine an object, we may see that each element in the object (part, line, edge, position, color, size) represents a decision. In very rough terms, we may say that each line represents a different decision.
Visible elements represent decisions made.
Software is made of decisions, too! This could be the angle for some kind of geometry of software. Can I tie it back to my thoughts on choices and sequences as the fundamental building blocks of programs? -> [Software as a sequence of decisions — article I read a long time ago; perhaps in my iA Writer notes?] -> [Choices and sequences — note I wrote long ago; iA Writer?]
We may also say that each line has created space on either side of it and near it, and therefore typically represents some four or five decisions about space (through size, convexity, adjacency, organization).
In addition, we must be conscious that larger elements, too (streets, house groups, courtyards, party walls, paths, blocks) — not only the smallest elements — must be included among the elements considered, and decisions about size, shape, and position of these larger elements, too, must be counted, since these also may be either flawed (with mistakes) or well-adapted.
Each element has the possibility of being wrong. By that I mean that the element as placed, sized, and oriented, may be well-adapted to its neighbors, to the space around it, to the conditions which exist, and to the conditions arising from the structure of the surrounding elements — or it may be badly adapted to the neighbors, conditions, space, trees, arising from surrounding elements.
What might the equivalents of the highlighted geometric properties and relations be in software? Is a decision in software is embodied through a conditional statement? Instructions are “placed” within functions, and classes, and modules — so they have a position in a hierarchical structure. That also gives them a level of scale. A low-level machine instruction is direct and lightweight, a higher-level function call is indirect and heavyweight, as it results in many more low-level machine instructions. As we group higher-level function calls within type classes, objects and modules, we allow them to have relationships with other things.
We are going to count the number of possible mistakes, and try to estimate how many of these mistakes have been avoided, and how many have been committed, in different types of plan. It is here, that we shall see the vast superiority of generated plans. They avoid mistakes. A fabricated plan cannot avoid mistakes, and in all fabricated plans, the overwhelming majority of possible mistakes, are actually committed.
#book/The Nature of Order/2 The process of creating life/6 Generated structure#