Heuristics

The ouroboros (οὐροβόρος in the original Greek) is an image or archetype of a serpent shaped into a circle, clinging to or devouring its own tail in an endless cycle of self-destruction, self-creation, and self-renewal. Becoming a good software designer sometimes feels like that.

Over time, we consciously and unconsciously build up our personal toolkit of design heuristics. Because I’ve seen so many workable solutions, I am hesitant to say any one is “best.” Yet, some are aesthetically more pleasing to me. I have my own style and distinct design preferences because of my background, that is, the collected set of heuristics and experiences I have assimilated. To grow as designers, we need to do more than simply design and implement working software. We need to examine and reflect on our work, put our own spin on the advice of experts, and continue to learn better ways of designing.

Billy Vaughn Koen, in Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving, defines a heuristic as anything that provides a plausible direction in the solution of a problem, but in the final analysis is unjustified, incapable of justification, and potentially fallible. Software patterns might be considered nicely packaged heuristics in that they provide a context for the problem, and offer plausible solutions along with forces that the designer needs to consider when implementing a solution. Like any heuristic, software patterns come with no guarantees that they will solve the current problem at hand. A dedicated group of authors in the patterns community continues to write patterns, collections of patterns, and more ambitiously weave patterns into pattern languages that attempt to cover paths to solutions in a particular problem space. Are we deluding ourselves about the utility of these efforts? Or is there something important about both the form and use of patterns in the larger context of design heuristics that we need to understand?

Over time, we build up a personal toolkit of design heuristics. I’m been designing software for many years and I’ve seen many alternative design solution solutions that work, so I am hesitant to say any one is “best.” Yet I have my own style and distinct design preferences I have accumulated over years of experience. You do as well. This talk will share a few design and modeling heuristics that were distilled during our pre-conference workshop and reflect on the difference between what works in theory and what we see in practice. And it will challenge you to grow as a designer by becoming more aware of your personal design heuristics and how they are shaped and evolve. You can grow as a designer by examining and reflecting on the decisions you make and their impacts, becoming more aware of seemingly minor decisions that were more important than you thought, and putting your own spin on the advice of experts.

Pattern authors ostensibly are experts on the topic their patterns address. Since most software developers don’t share those experts’ underlying design values, practices, and principles—let alone their design context—there’s a disconnect between what is said in pattern descriptions and that which is perceived and understood by pattern readers. As pattern readers, we will be better equipped to grasp the significance of these software patterns if we also gain insights into the design principles and values that they are based on and some reasons why they “work” the way they do. But it is through experience, practice, and reflection, that we deepen the connections between new-to-us patterns and our existing knowledge, and expand our design umwelt.

With experience, we learn to nudge our designs in directions we want them to go, using patterns along with countless (unnamed) personal design heuristics. Our perception of our current design context, as well as personal preferences and design values, lead us to apply particular heuristics and choose a course of action. When learning about any new software design patterns, techniques or heuristics, we view them through the unique lens of their past experiences. And we implicitly add and enrich any new design technique or practice based on our existing design umwelt. Umwelt, from the German, means "environment" or "surroundings” and includes our perceptions of the world as well as our actions to produce a desired effect or change. Our umwelt isn’t static; we reshape our umwelt as we interact with our world, gaining skills and learning to perceive differently. It is our umwelt that both drives and limits our potential actions.

One way to learn how to exercise judgment, develop discernment, and stretch our design umwelt is to perform structured experiments. In this hands-on session, we’ll start off sharing some of our cherished design and testing heuristics and practices. We’ll speculate on some of the “whys” behind why some of our favored heuristics work the way they do. And we’ll practicing picking up subtle cues from our design contexts that may lead us to either apply adapt specific heuristics, discard them as not fitting our current design context, or to seek out new ones.