Notes on Design in Practice

Rich Hickey's talks have been influential in my thinking about building software, in particular his thoughts on the importance of "hammock time" and craftsmanship.

Rich's latest talk is titled Design in Practice and clarifies a structure of building and recording a design that I feel is "just enough" to helpful without being burdensome. Further it elaborates Architecture Decision Records (ADR), which is the design structure I'm most familiar with. I still refer back to Mike Nygard's post on ADRs from 2011 regularly.

Notes on Design in Practice

video: https://www.youtube.com/watch?v=c5QF2HjHLSE

full transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignInPractice.md

This talk is about formalizing the process of design. Given Rich's background, he's primarily talking about software design but you may apply these concepts to other domains.

Some of the benefits and goals include

• make hammock time more effective
• return to our design thinking context quickly
• help others to join into the design thinking context
• final solution will be both smaller and more general

He begins by talking about precision in words. Using precise words helps keep wording concise and makes understanding easier. An artifact of using precise words is a glossary.

Rich reminds us the questions and the Socratic method are powerful tools for building understanding. Exposing answers to find the truth helps everyone learn. Detach yourself from your ideas. There is an objective truth and the goal is discover it together.

A framework for questions:

• Where are you at?
• Where are you going?
• What do you know?
• What do you need to know?

These questions frame your current status and your direction, from both progress and understanding. Rich suggests these questions can help with reflective inquiry; being aware of your own thinking.

He suggests that we should try to structure the record of our design in stories. A story should have these sections:

• Title
• Description
• Problem statement
• Approach

Not a checklist. Goal is record decisions made and why.

The suggested phases that a design process follows are:

1. Describe (situation)
2. Diagnose (possible problems)
3. Delimit (the problem you are going to solve)
4. Direction (strategy, approach)
5. Design (tactics, implementation plan)
6. Dev (build it)

Rich continues to explain the 6 phases.

Describe

• write down what you hear or know
• describe the symptoms
• how big is the problem?
• what is the impact of the problem?

Diagnose

• accumulate hypotheses (there's always more than 1 possible reason!)
  • explore hypotheses one at a time
  • use scientific method

Delimit

• did you discover many problems? We need to delimit them so we can find a clear path to solve one problem.
• clearly scope the problem

Direction

• describe high level approaches to addressing the problem, and trade-offs
• try listing approaches in a matrix or spreadsheet
  • approaches (columns), criteria (rows); what aspects of each approach addresses each criteria?
    • criteria examples are how long will this take to build? or does this meet our legal requirement?
      • If struggling to find criterion, start with listing pros and cons
• goal is to judge the approaches and determine best

Design

• Similar techniques to above to determine implementation path
• May discover that problem is not well scoped or direction criteria are incomplete, in which case you backtrack and make updates

Published: 2023-08-17

Tagged: talk clojure design richhickey