Books | The Responsible Designer	
Growing Your Personal Design Heuristics Toolkit
Billy Vaughn Koen’s Discussion of The Method has had a profound influence on my thoughts about design. This book has inspired me to explore the role that software patterns play alongside other design heuristics and led me to muse about design uncertainty. I’ve been inspired to experiment with simple ways to capture design heuristics and I’ve spent time heuristics hunting with other designers.
In this blog post I’ll introduce you to Billy Vaughn Kohn’s ideas about problem solving and heuristics. Billy defines 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.”
There are no guarantees. Heuristics can fail. The tenacity that defines an engineer is when she steps back, regroups, and finds a different heuristic to try next. Another important thing to consider is that there are always competing heuristics to choose from. There simply isn’t a single right way to solve any complex design problem. Based on our assessment of the situation, our judgment, and the fit of the heuristics we know to the problem at hand, we decide what to do next. And when designers disagree, it may be because they are focusing on different aspects of the problem, or that they have a different collection of cherished heuristics in their toolkit (whether or not they can articulate them).
Courtesy of xkcd.com https://xkcd.com/309/
Billy describes three different type of heuristics:
1. Heuristics we use to solve a specific problem;
2. Heuristics that guide our use of other heuristics (meta-heuristics, if you will); and
3. Heuristics that determine our attitude and behavior towards design or the world and the way we work.
Heuristics we apply to solve a problem. For example, in his book, Billy gives several examples of general engineering heuristics: Heuristic: Always be prepared to give an answer (and when you need to give an answer, use the best approach you know for figuring out that answer based on the time constraints and resources you have at hand). As an example, imagine the approach you might take for determining the number of Ping-Pong balls that fill up a room if you had to give an answer in 2 seconds. What if you had 2 minutes, an hour, or a week to come up with an answer? Would your approaches differ?
Heuristic: Use feedback to stabilize your design. Billy Vaughn Koen is a Professor Emeritus of Nuclear Physics as well as a philosopher of engineering. He taught people who designed nuclear reactors. I’m glad he taught them about the importance of feedback loops to verify design assumptions. And that is one reason why frequent delivery of software, retrospectives, and reviews are valued activities in agile development.
And oh yes, one last heuristic: Always give yourself a chance to retreat. Backing out of a half-baked or unworkable design is important if you don’t want to paint yourself into a corner.
As software designers we have many heuristics in our toolkit. If we know about design patterns, we use them. If we’ve built high-performance systems, we may have a wealth of heuristics for tuning cache performance. If we are familiar with Domain Driven Design concepts, our preferred way to structure a complex system is by identifying bounded contexts. For those unfamiliar with Domain Driven Design, a bounded context might be considered to be roughly equivalent to a subsystem or subdomain. The distinguishing characteristic of a bounded context is that within it there is a consistent, single, unambiguous meaning for business concepts and events. And we may visualize event flows and relationships between bounded contexts by drawing a context map.
Heuristics that guide our use of other heuristics. These heuristics tell us what to try next. The best examples I know of these heuristics are in Object-Oriented Reengineering Patterns. Each chapter in this book is a small pattern language, describing a rough sequence of actions for solving a particular system-reengineering goal. For example, chapter 3 is a pattern language for making “first contact” with a legacy system. Based on what you have just learned, the language spells out options for what to explore next.
Heuristics that determine our attitude and behavior. Agile software designers value frequent feedback. That’s the premise behind frequently deploying working software in order to have its functionality exercised by actual customers. And one heuristic for reducing the risk of downtime when frequently deploying software is to use a blue/green deployment environment.
While we may have learned design patterns (or other published patterns, for that matter) by reading about them, most nitty-gritty design heuristics come from on-the-job experience. We learn a lot by living with the myriad design choices we make (and revisit) as our system’s functionality grows. We learn even more as we support a system over its lifetime. Our heuristics are shaped not only by the kinds of software systems we have designed, built, and maintained but also by the design culture at our places of work.
How do we improve as designers? Through designing and building software. By reflecting on that experience. And by polishing and refining our heuristics and sharing our cherished heuristics with each other.
Posted in Books, Design Heuristics, Software Design	| Leave a reply
Posted in Agile, Books, Psychology	| Leave a reply
Posted in Agile, Agile Experiences, Books, patterns, Uncategorized	| Tagged fearless change, patterns	| Leave a reply
Posted in Analysis, Books, Psychology	| 2 Replies
Posted in Agile, Books, Christopher Alexander, Half-baked Ideas, Programming, Software Design	| Tagged Christopher Alexander, lively processes, software development processes	| Leave a reply
Architecture Patterns for the Rest of Us
Recently I have been reading and enjoying Robert Hanmer’s new book, Pattern-Oriented Software Architecture for Dummies. Disclaimer: In the past I have shied away from the books for dummy series, except when I wanted to learn about something clearly out of the realm of my expertise. Even then, just the notion of reading a book for dummies has stopped me from several dummy book purchases. Good grief! I didn’t know what I have been missing.
This book is not theoretical or dry. The prose is a pleasure to read. And it goes into way more depth than you might expect. Instead of simplifying the Patterns of Software Architecture book that is also on my bookshelf, I’d say it adds and complements it with clear explanation of benefits and liabilities of each pattern, step-by-step guides to implementing each architectural pattern and more. As an extra bonus, the first two parts of the book contain some of the clearest writing about what patterns are and how they can be used or discovered that I’ve seen.
I wish Bob Hanmer would write more patterns for the Dummy series. He knows his subject. He has good, solid examples. And he doesn’t insult your intelligence (In contrast, I find that the Head First books are definitely not my cup of tea…I don’t want to play games or have patterns trivialized). Bob has an easy, engaging style of writing. The graphics and illustrations are compelling In fact, I reproduced a couple of the graphics about finding patterns in a lecture, with credit to Bob of course, in a lecture I gave last week to my enterprise application design students.
This is a good book. If you’ve wondered about software architecture patterns and styles, read this book. Buy it. And tell your software buddies about it, too.
Posted in Books, Software Architecture	| Tagged architecture, dummy books, Robert Hanmer	| 1 Reply
Posted in Books, Software Architecture, Software Design	| Tagged books, domain-driven design, software design, Vaughn Vernon	| Leave a reply
Working–share your experience
Posted on February 20, 2007 by Rebecca Wirfs-Brock	
One of my all time favorite books is Studs Terkel’s Working. In it, he captured people talking about what they do and how they feel about it. People tell amazing stories about hard work. The book is about, “ulcers as well as accidents, about shouting matches as well as fistfights, about nervous breakdowns as well as kicking the dog around.” I hope you don’t find software development so grim (I don’t ). But maybe you have an intriguing story to tell.
OOPSLA is soliciting Practitioner Reports. The submission deadline is just a short time away–March 19th. If you submit a report and it is accepted, Ralph Johnson or one on his committee will help you tell your story. There are many more interesting stories to be told and if you have one, please consider telling it at OOPSLA. Last year there was a really great story about how software objects finally made it to space in a JPL satellite through the persistence of a guy who really, really believed in the benefits of oo programming. A grad student at Portland State presented his experience exploring Traits–when he was an undergrad. I remember another report where a developer recounted his use of refactoring tools to write transformation rules to transmogrify a massive Smalltalk legacy application’s database access layer. And I recall another telling how a framework for scientific applications evolved. There are always interesting stories to tell; and OOPSLA is a place where you can tell them, whether they be about your latest adventures with web services, domain-driven design, aspects, agile or open source development, or the challenges of developing applications in distributed teams.
Posted in Books, Events	| Tagged experience reports	| Leave a reply