a Trace in the Sand

by Ruth Malan

 

 

 

 

February 2019

2/8/19

2019 OReilly Software Architecture Conference NYC: Visual Design and Architecture

[in process] Annotated Presentation Slides

Visual Design and Architecture Cover SLide

 

Part ii: Why Visual

As we transition to talking about visual design and its role in designing how the code will be structured and how the system will be built to yield those capabilities and properties, let's take a step back and consider what we get from making design visual.

Drawing on the walls since way back

Drawing on the walls is not new—we've been doing it since at least 33,000 years ago! If you haven't seen Cave of Forgotten Dreams, about the Chauvet Caves in France, you're in for a treat. Only discovered relatively recently, and, with few exceptions, closed to view, it is a striking and touching connection with amazing artists living so long ago. And it speaks to the value of images in conveying across time, but also the limitations. While the paintings marvellously capture animals including species not recorded in other cave paintings, they don't tell us much about human life at the time. We make guesses about the uses of the paintings, but they're guesses.

Even real engineers draw on the walls!

Jump forward tens of millennia, and we have engineers drawing on walls. This scene with (Taraji P. Henson playing) Katherine Johnson in Hidden Figures, wonderfully captures why. We draw "out loud" (so to speak) to help ourselves reason, to help others follow our reasoning or to explain it, and to collaborate—to create a "shared thoughtspace" where others can understand our idea and the reasoning that supports it, add to it, get ideas of their own, and so on. "I see what you mean" is literal. And in seeing, and hearing the thinking that also helps illuminate what is being drawn, we can question our assumptions, catch flaws, share different perspectives and alternatives we see, and more. Fundamentally, we're sharing, teaching/learning, and/or collaborating in a dynamic live-interaction way, so we can respond to questions, and ideas or concerns, capture more of the picture, the forces in play (including the "politics" and elephants and hippos in the room), etc.

Engineering notebooks go all the way back to Leonardo Da Vinci

Engineering notebooks have an inspiring history too. I used to think of Leonardo da Vinci as an artist-inventor, and it wasn't until I read Engineering and the Mind's Eye that I realized how much of a scientist and engineer he was—recognized as such in his day, too, holding official positions as engineer including "painter and engineer to the Duke", and “First painter, architect, and engineer to the King.”

Da Vinci was intrigued by problems like inertia, friction and resistance, and investigated mechanisms and mechanical elements such as screws and gears, pulleys and weights, with a piqued visual curiosity. One of the things that stands out for me, in Da Vinci's method of studying anything from physics to anatomy, is that he sought to understand not just structure but dynamics, and the interaction of structure and dynamics, or how things work and the principles that govern how they work. And he used his illustrated notebooks to document and pursue his study. It is clear he used the pen to see, to observe more closely, and more closely still, to probe and explore structure, and the principles of dynamics that relate structure, constraints and behaviors. And more. His notebooks served not just to record, but to teach—himself even. Drawing and note taking was an instrument of learning about what he was probing with his eye, his mind, his mind's eye, and what he externalized on the page, pages, volumes.

"A recent and exhaustive analysis of Leonardo as a scientist by Fritjof Capra argues that Leonardo was a fundamentally different kind of scientist from Galileo, Newton, and other scientists who followed him, his theorizing and hypothesizing integrating the arts and particularly painting. Capra sees Leonardo's unique integrated, holistic views of science as making him a forerunner of modern systems theory and complexity schools of thought" — wikipedia

Da Vinci used sketches to make new connections, to sketch prototype and invent

Da Vinci advanced various fields of science and engineering, figuring out, and prefiguring advances that we often ascribe to those who came after him: he foreshadowed Copernicus by 40 years, declaring "IL SOLE NO SI MUOVE" ("The sun does not move.") And adding, "The earth is not in the center of the circle of the sun, nor in the center of the universe." Further, 200 years before Newton, he wrote "Every weight tends to fall towards the center by the shortest possible way." He was likewise prescient in other fields. 400 years before Darwin, he placed man in the same broad category as apes.(Gimpao Ni Ei Suuh)

Da Vinci's notebooks capture and extend understanding of phenomenon of nature and machine, and include numerous inventions, some built in his time, others later—such as the lens grinding machine pictured. These inventions, we might note, were constructed as sketch-prototypes so compellingly drawn as to both persuade feasibility in many cases, and to inform construction. (The Archimedes steam cannon is a fun story).

Though his scientific notes are articulate and precise, for da Vinci, illustration took precedence—the drawing does not illustrate the text; rather, the text serves the illustration, only adding detail best expressed in words. To this end, he developed principles of graphic representation—stylization, patterns, and diagrams.

An architecture expressed in words

As important as sketches, visual models and annotated diagrams are to thinking alone and collaboratively, and over time, a lot can be done in text. Take the architecture of the US government—its key principles, structures, and mechanisms, are described in the US Constitution. It is marvelously minimalist at just 4 pages.

And more words, in the form of the Federalist Papers

It is expanded on in the Federalist Papers, which are reasoned arguments for different aspect of the Constitution. They take a technical white paper form, describing the context and problem, the solution approach and how it addresses driving concerns, and implications.

Ward Cunningham Technical Memo

And in Episodes, Ward Cunningham advocated writing short, to-the-point, technical memoranda to address key subjects not expressed in the code, that need contemplation and reflection, and involve enough detail that they are not easy to recall.

Thing Explainer

Still, the power of adding sketches or visual models is evident in Randall Munroe's book, Thing Explainer. Randall set himself the constraint of using only the 1,000 most commonly used words, and the book works astonishingly well. (Note, the words constraint was for fun, not to be condescending to kids.) Partly, it works so well due to Randall's grasp of these various systems, and is a function of strong visuals, along with the annotations. I recommend Thing Explainer to architects a lot, because that's what we need to see ourselves, in good part, doing—understanding structures and mechanisms and explaining them. And doing so with the aid of sketches, where we can make the concepts and dynamics visual. More on that soon.

For now, let's just underscore: as we train ourselves as architects, we'd do well to be taking Leonardo da Vinci and Randall Munroe as inspiration, using drawings illustrated by text to discover and teach the design principles that underlie our complex systems—for our own systems, and others. Study design, through the pencil. And communicate design, through the marker. And other diagramming or modeling tools, as and when we want to convey something more polished and thought out.

Simon Brown: diagrams for communication and learning

Diagrams and text serve importantly to communicate and learn, but I want to add to Simon Brown's point

Diagrams in design -- for better designs

that we use diagrams or visual models in design to do design. To create better designs, and to express our designs. True, this helps in communicating our designs and sharing what we've learned, and have to convey.

Spiders use what they put in the world to think

We're learning about embodied cognition (involving more than the brain) and extended cognition where we use the world to think—not just externalizing memory to books, notes, the internet, but also using the world to think and reason. Like using an abacus to do calculations. And it turns out even spiders appear to use their webs as devices to figure out what to do (next). For example, extending their web in the area where bugs have been caught.

Statement of monk and mountain problem

So here's a problem to illustrate. Imagine a monk starts up a mountain at 8am and arrives at the top at 8pm. and the next day returns by the same path, starting at 8am and getting to the bottom at 8pm. Can we say with confidence that he was at the same point on the path at the same time of day, on the two days? How do we know?

Visual solution to monk and mountain problem

One way to think, is to draw, and the diagram illustrates that we can say yes. Another way to think about it is each of my hands is the monk on the two days, and one hand will move along the path in one direction, and the other hand is the monk starting at the other end of the path, and moving in the other direction on the same path. My hands have to meet at some point, at the same time. As important as the illustrations are to the point that we can put something in the world to help us think, it's also illuminating that some people will still not see it, and these people are important too. We can try to illuminate the solution different ways, but our perspectives differ, we're looking for a catch, and trust and credibility may factor, etc.

making it visual, helps us think better, together, and over time.

To be agile, that is to be responsive (which includes sensing as well as responding), adaptive and resilient, we need to learn in the quickest, cheapest medium that does the job. With sketches and models, when that allows as to probe and explore, and discover well enough, for the moment we're at. A sketch prototype is easy to reverse or back out of—at least, it is as easy as letting go of our ideas, which can be hard, I acknowledge. But easier than code we build to experiment, though we do that when models don't give us enough insight. The key idea is not to return to "big design up front," detailed out in models, but to use sketches and models as a design aid throughout. Some upfront, and more along the way. It is a tool in our design toolbelt. And we need to be okay reaching for that tool, when it is good enough for the decisions and design work at hand.

Sketches, diagrams, visual models (of facets of the system) have benefits over text in terms of showing relationships and interactions, and leverage what our visual perception is good at -- spotting patterns, noticing what's missing or surprising. We can use placement and color and figure to show, and we can use what is not shown, to express, To enable us to cope with complexity, by abstracting away detail unnecessary to what we are currently reasoning through.

Models help Reason, Explain, Design, Communicate, Act, Predict, and Explore (forming the acronym REDCAPE) from Scott E Page, The Model Thinker. (Via Alan Hakimi)

"Maps help us see fuller picture, devise/test strategies" — Brenda Michelson

Using drawing to observe more closely, to notice relationships and patterns, studying systems in terms of structure, dynamics and properties (and tradeoffs among them) to diagnose and improve, to get more the properties we want and/or less of what we don't want.

In sum, making it visual, helps us think -- better, together, and over time.

Using diagrams and visual models to convene and convey

When we say that we value "people and interactions," in part (I think) we're saying we value collaborative work to get things done, over the "stocks and flows" of documentation and workstages. And in-person collaboration happens in a context -- it may be convened around a keyboard, or a whiteboard.

We use drawing together, on the walls (or whiteboards), to convene collaborative design work; it convenes the conversations that inform. Inform the design work, and inform those doing it. As we draw out, we draw in. Working together, unfolding the design, engages minds (and hands, in the embodied cognition sense). Participation persuades. (Which has its dangers, and we have to be aware of our inattentional blindness and other cognitive and group biases, etc.) Sure, we can mob program, and do. The point is, we can mob model too.

Note: This is a work-in-progress. More to come. If this is useful, saying so will help give impetus to this "continuous delivery" writing project :-)

 

Table of Contents: Annotated Presentation Slides

Slides and Annotations. Note: broken into parts because with the slides as images accompanied by annotations, it makes for a big download. Even split into parts, it's a lot to download, so don't use cellular to access unless unlimited plan and lots of patience hitting refresh. :-)

Part i. Slides and Annotations: Introduction and Context setting around Design in Agile; Decisions and Constraints; Decisions and Tradeoffs; Getting to know the domains (contexts of use, development and operations, value partners and others); Design and expressions of system value, capabilities and properties

Part ii. Slides and Annotations: Why Visual Matters to Design, some exemplars we can learn from, and lessons we can draw about why we need to bring visual models back into our design toolkit (some already do, obviously, but why more of us need to)

Part ii. Slides: All the slides are here, but this section still needs to be annotated. It covers architectural design of the system (internals). More to follow.

All, Parts i, ii and iii. Warning: big file to download as there are lots of images due to all the slides. Parts i and ii, slides with annotations and Part iii, just slides so far.

Visual Design and Architecture Slides on Slideshare

PDF here

Thank you to everyone for the mentions, likes and retweets and reshares on the various social media.

 

3/9/19

Workshop News

We have two open enrollment workshops coming up, one in the US and one in Europe. If you're interested in a Software Architecture Workshop elsewhere, do let us know. In particular, Dana Bredemeyer is looking at doing an Asia-Pacific "architecture tour" later in the year.

There's still space in both workshops:

About My Work

 

I also write at:

- Bredemeyer Resources for  Architects

 

Software Architecture Workshop:

- Dallas, TX, on April 29-May 2, 2019

 

Journal Archives

- Journal Map

 

2018

- Current

2017

- December

2016

- January
- February
- April
- May
- June

2015

- June
- July
- August
- September
- October
- November
- December

2014

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November

 

More Archives

 

 

 

 

 

Architecture astronaut

 

 

 

 


Copyright © 2019 by Ruth Malan
https://www.ruthmalan.com
Page Created: February 9, 2019
Last Modified: April 1, 2019