TITLE: Design as Choice AUTHOR: Eugene Wallingford DATE: August 01, 2006 7:16 PM DESC: ----- BODY: Last week, I quoted Bob Martin on the interplay between design and building:
You always have to design something before you build it. The question is: "How much do I have to design before I build?" ... the act of building is *part* of the act of design....
To many people, this sense of design is heresy. They prefer a more formal definition, one that makes clear a distinction between between design and implementation, and analysis and design. Even in a day where iterative models of software development have replaced the waterfall model in the minds of even the most traditional software engineers, many people still think of the phases of development as very different. Agile software developers seek to iterate more quickly through the phases of software development, in large part because of what Martin reminds us: we learn too much about our design from writing code to wait very long to begin writing code. Likewise, we learn too much from our design and coding about how well we understand our problem to wait very long to begin designing and writing code. So, what is the best definition of design for us to use in our work, and with our students and new hires? Folks who see the phases of software development as Major Events to be seen as separate activities are most likely to give Major Definitions to the phases. But I've learned a lot about design from folks who have more pragmatic takes on software development. Sometime last year, the members of a mailing list I'm on discussed the definition of design. Jim Coplien and Grady Booch gave very thorough definitions of design, both the verb (the act of designing) and the noun (the artifact produced). Both of their definitions incorporated the idea of a system and its behavior, related to the forces that exist in the system's intended environment. The thing I liked best about Booch's definition was how it managed to account for the scientific side of design, where empiricism and experiment help us to make optimal decisions in a large search space, as well as the artistic side, where science leaves enough degrees of freedom to enable clever and elegant decisions. Whatever else design is, it is about the choices we make while building things. Some of the features of a system are required by the customer, and others are driven by the technologies that we use, including the programming language. The rest of the system is determined by the developer. This is how James Noble characterized design in our e-mail discussion: the decisions we make that determine the rest of the system. By the way, Noble's definition reminds us just how important it is not to use an overly restrictive programming language when we build systems. Such a language makes too many decisions for us upfront, without regard the problem we are solving or the environment in which the system will live. Choosing such a language surrenders too much freedom, too much possibility, too soon. Once we get to the point of seeing design as being about choices, and without any predisposition to create a complex definition in order to distinguish design in some formal way, we can get to my all-time favorite one-line definition of design. This definition is courtesy of Ward Cunningham, whose gift for simplicity I have extolled before:
Design is your choices that stick.
This brings us back to the fundamental truth in the agile approach captured by Robert Martin in the passage above: Not all of our choices will stick, and we need to learn which will and which won't as quickly as possible, from whatever sources we have available. And that includes the program itself. -----