A Trace in the Sand
by Ruth Malan
What's This Then? A Trace? In the Sand?
This is where I keep a trace of thoughts on wanderings in the landscape of software and systems architecture and those that abut and have bearing on ours.
On February 3, this Trace will be 10 years old!
A few people are extremely generous in terms of giving exposure to my Trace through retweeting my links to it, or by mentioning it: Gene Hughson, Amitai Schlair, Paul Harland, Stuart Boardman, Cory Foy, Eugene Barker, Brenda Michelson, Vish Persaud and Ernest Buise have all been most kind. And Grady Booch, in addition to several retweets over the years, also links to my site from his Handbook of Software Architecture site! Other people who have been kind with retweets and mentions include Sally Bean, Andra Sonea, Mark Burgess, Marc Burgauer, Martin Howitt, Tom Graves, Arnon Rotem-Gal-Oz, JP de Vooght, Gernot Starke, Matthew Skelton, and Richard West. And recently, Matt McLarty and Mike Amundsen kindly mentioned my Conway's Law post and traces -- with enthusiasm even! And Uwe Friedrichsen mentioned my trace on empathy. Gratitude too, to a dear friend and a leading thinker in the software architecture space, Charlie Alfred. There are also a few people who have dropped off Twitter -- foremost Peter Bakker. [Update: He's back!! Yay! Great avatar!] And my long-time good friend, Daniel Stroe.
I tend to use visual design and design visualization interchangeably, and that's okay with me. :) But I also think it is worth separating, as follows:
In both cases, we are doing design -- we're seeking to make our systems more the way we want them to be (i.e., design, after Herbert Simon). And using visual expression to give ourselves a cognitive assist. Which we need, because our systems are complex, and hard to hold entirely in mind. If you see what I mean? You don't? I should draw it?
Now, Da Vinci did both visual design and design visualization in his sketchnotebooks. That is, he created new designs and designed inventions. And he expressed (key facets of) (existing) designs he saw, realized in the world, that interested him, to study them and communicate them. In the terminology I used in the talk/slidedeck/slidedoc, he used the iconic visual language he developed, to both express design intention, and to express realized (built) designs.
In our case, we very often use a quite different set of visual expressions for design intention and realized design. In part, this is because we direct tools at massive codebases to help us visualize what we can, by having an "objective" and exhaustive instrument (compute) extract design information. And this skews what we are looking for and at, towards what is computable. So-called "tribal knowledge" (in our heads and conversations, assumptions, etc.), for example, is not [yet? ;-)] computable.
Update: Vish makes a nice distinction:
I don't want to bury the contribution under "it's obvious" -- expression of intention (and exploration as we conceive, modify and improve intention) differs from how we (using tools) reflect the design as built. What the talk (slidedeck) does, is lay out the landscape of visual design and design visualization, so we can see it, analyze it, improve what we get from it. The slides and slidedoc are valuable. But I can only say that so many times. At some point, someone else has to glimpse the value and say "ahhhh. Oh hey. This is useful!" Or something.
For those who can't read my scrawl -- put on your glasses! No, I mean, allow me to translate: our design expression creates a "shared hallucination" (we're being playful; bear with me) -- one in which the dream (design conception, which as we mature it, becomes design intention) informs/shapes and improves reality (double entendre of sorts there, because the system -- hopefully -- improves the broader reality by being in place, but the design hopefully also makes it a better system; better than it would have been if the design was entirely/more ad hoc and accidental). And, turning our attention to the lower return arrow: (our perception of) reality in turn prompts us to improve the dream (design conception/intention). But (focusing on the dream-dream arrow) the dream (design conception -- and its expression via sketches and descriptions, sketch prototypes; prototypes; code slices; etc.) is also an arena for learning and improving the design.
Data Visualizations 2015 Awards: analog wins one!
1/16/15: With respect to features being visible, I do so resonate with this:
I never said I was always right. ;) As designers, we (ideally) aim for systems that have natural affordances, and that don't obtrude into and obstruct or interfere with what users are trying to accomplish with the system. In getting at the architecture of a system, we're after perceiving the significant structures and their interrelationships, the emergent properties and mechanisms by which the system delivers its capabilities. That. But also the ideas, the reasoning, the intuitions, the constraints taken into account, and ignored, and so forth, that shape the system and lend it integrity or wholeness. To the extent that the system has integrity (design integrity, structural integrity, ...).
Push any idea far enough, and it wants to be a book. Or at least, a completed slidedoc. :)
1/25/16: Please note, though, that I think we really do need to keep design visualization open also to visualizing (future) designs/design improvements/design possibilities. That is, I like that design visualization as a term, contains both visual expression of design intent (or playing with intent, to better understand what we intend, or could make possible in the world) and visual expression of the design of the built system, to bring into focus some aspect(s) of the design as built/realized. That "ex-post observability" term JP deVooght used today. :)
Reading the brief, but now so poignant, interaction between my daughter and my 15 year old nephew on Facebook as we were en route to South Africa... He died in a tragic accident the morning we got there. Everything. It all just breaks the heart! Some things are so unbearably hard! If we put our children in cotton wool and made them stay at home to be safe, we'd kill their spirits. If we let them out into the world, we risk having our hearts broken so bad! Josh was a beautiful person who took delight in, and gave such delight to us! I am so sad for his direct family. So sad for all of us who will miss his growing from teen to manhood. We have memories to treasure, but they also hurt!
Some girls from his school put bottles with messages in them, into the sea.
Life. Ours, those we love. It's fragile, and precious!
Software Architecture Workshop
Also, finalizing date for an Enterprise Architecture Workshop in April/May, working around client commitments.
A trace by this title from back in 2012, began:
"Organisms" may sound a bit iffy. Let me back up. From an earlier trace:
That said, hopefully the Minecraft example helped a bit:
And... architecture? Oh, so now you want the notes to this slide?? ;-)
Well. Why didn't you say so?!
Something something Wardley Maps? Yes, and...!
Finding the Right Cleavage
That's a better title than "responsibility factors in design" or something responsibility-oriented like that? (Is propensity to "change together" conjoint with -- that is, the dual/flip side of -- responsibility-centered cohesion? In other words, does cleaving along lines of responsibility, tend to be the same as cleaving along lines of what changes together?) At any rate, it's a trace I ought to write, to explore that territory again. And a title I ought to use, as a Jester's joke? See if link clicks through to my site go up -- to like, ONE. Sheesh world. The high expectations the field has of (this) women in tech????
Well, at any rate, it's a chance to point to Cook Ting.
1/22/16: I don't even get to make it to the Imposter Syndrome base -- I have to fight the
Not a Detour -- It IS the Tour
I opened with "This flight is going to Indiana by way of South Africa."
Sometimes, to get to where you're going, you have to go somewhere unexpected first -- because you don't know where "there" is, or why it matters.
How Hard Can It Be?
I mean, it must be hard, but... Okay so, the Visual Design slidedoc reports 2616 views, but slideshare analytics (available to the account holder) reports 682 views. That's... quite a big difference. And the latter is closer to right, given the links from Twitter as reported on tweets linking to the slidedeck (0 to maybe 3 clicks, for the most part).
Also, this happened -- buried down in a discussion thread, but still a nice little brush with positive feedback:
I also write at:
- Bredemeyer Resources for Architects