Rebecca is an object design pioneer who invented the set of design practices known as Responsibility-Driven Design (RDD) and by accident started the x-Driven Design meme. Along the way she authored two popular object design books that are still in print. She was the design columnist for IEEE Software. You can find her design columns, papers, and writing at www.wirfs-brock.com/Resources.html.
In her work, Rebecca’s helps teams hone their design and architecture skills, manage and reduce technical debt, refactor their code, and address architecture risks. In addition to coaching and personal mentoring, she teaches and conducts workshops on Responsibility-Driven Design, Pragmatic TDD, enterprise application design, agile design skills and thinking, being agile about system qualities, and Agile Architecture. In her spare time she jogs (even in the rain).
Rebecca is also program director of the Agile Alliance’s Experience Report Initiative. Another interest of hers is software patterns. She serves on the Board of the Hillside Group and recently has written an essay about the relationship between patterns and heuristics, patterns about how to create and manage magic backlogs, sustainable architecture, agile QA, and adaptive systems architectures. If you are interested in writing about your experiences or sharing your wisdom in pattern form, contact Rebecca. She can help you turn your itch for writing into the written word.
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.
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. We all use heuristics (even if we haven’t articulated them to others) to discover, understand, explore, create, modify, or extend complex software systems. 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 aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.”
Software and architecture patterns are one form of neatly “packaged” heuristics. Patterns don’t just tell a designer what to do. Instead, they provide a rich context explaining under what situations the pattern has been found to be useful, tradeoffs to consider, and an outline of a potential solution and consequences of applying that solution. Anti-patterns are another form of heuristic. They describe how a well-intentioned solution can cause even more problems (and how to back up and recover from them). Terse statements can describe simpler heuristics.
In addition to solving a specific design problems, heuristics can guide how we work, evaluate design choices, generate ideas, or even what we choose to work on next.
In addition to patterns and other heuristics we learned from others, each one of us has crafted our own personal heuristics through years of experience. Over time, we consciously and unconsciously build up our personal toolkit of design heuristics and modified and embellished on those we’ve learned from others. We each have own own style and distinct design preferences because of our background, that is, the collected set of heuristics and experiences we have assimilated.
This workshop is a forum for exploring, articulating, and sharing our personal heuristics. After a brief characterization of what heuristics are, we’ll dive into hands-on exercises that help us explore and articulate our heuristics for understanding a domain and architecting and designing systems congruent with Domain-Driven Design values and goals.
One outcome of this workshop will the identification of new or more nuanced heuristics we’ve articulated, as well a map of the territory they cover. As we map out our personal heuristics and share them we are likely to discover competing and conflicting heuristics. We may also work out some promising ways to characterize heuristics.
Missed #DDDEU?
Get tickets for the next edition
