A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

June 2013


What's a Trace?

For 7+ years, this journal has contained notes I've taken as I explored what it takes to be a great software, systems and enterprise architect. That's a long time, and a lot of exploring, wrestling with understanding, and simply noticing and celebrating. Too much really. I should go back to thinking outside this box; and I am creating some better organized boxes for the work I share. :-)

I closed out May early, so as to "turn over a new leaf." :-)

But.. that didn't last long:



#Fail Blogger

I created my informal blog on Blogger just to try that out. But... I hear that Blogger is pretty inhospitable to those who try to comment from outside Google's imperialist base... That's really unfortunate. So sorry about that.


Surfaces and Essences

While a cycle out into a glorious after-the-storm evening light blew the funk right out of me, it was Surfaces and Essences that set my spirit back to full flame. There is a lot that is familiar, given that, over the past several years, I have been reading papers and watching talks by Douglas Hofstadter on analogies and thinking. At times the book is rather ponderously didactic, not making much allowance for the quickly grokking playful skipping mind that it is talking about! ;-) But my, my, at others it is delightfully, exquisitely vibrant! Making full use of analogies to hue sentences that just radiate. Anyway, I do recommend it with warmth and reason. We use analogies to think, to learn, to communicate and to create.

Sometimes I think that it would be fun to vamp a method called Design by Analogy (or summat of that ilk) to get this important tool a decent place on the software development toolbelt. But it seems like this clan-oriented software world needs tribal leaders who assert and muster a kind of single-minded allegiance to break into the attention space. Which doesn't appeal to me in the least, because such skewed single-mindedness has a maladaptive fit in this highly shaded, complex world.



Balance the Deck?

So, hey, how long do you think before someone will suggest that I be invited to keynote at one of these things to balance the upper deck a bit? I should write a book? Oh, right.

EA conferences have a better ratio of women to men than most tech conferences -- at about the ratio of women to men in the industry. But still too often have all men in the top slots.


Some Laws to Keep in Mind

From wikipedia, for expediency:

Parkinson's law of triviality, also known as bikeshedding or the bicycle-shed example, is C. Northcote Parkinson's 1957 argument that organizations give disproportionate weight to trivial issues.

Conway's law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968. It states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

Gall's law – "A complex system that works is invariably found to have evolved from a simple system that worked."

Poe's law (poetry) – There is a maximum desirable length for poems: "The unit of poetry must be fixed by the reader's capacity of attention, and ... the limits of a poem must accord with the limits of a single movement of intellectual apprehension and emotional exaltation," named for Edgar Allan Poe.[3][4] See "The Philosophy of Composition".

Postel's law – Be conservative in what you do; be liberal in what you accept from others. Derived from RFC 761 (Transmission Control Protocol, 1980) in which Jon Postel summarized earlier communications of desired interoperability criteria for the Internet Protocol (cf. IEN 111)[8]

A power law is a functional relationship between two quantities. For example, if the frequency (with which an event occurs) varies as a power of some attribute of that event (e.g. its size), the frequency is said to follow a power law.

The second law of thermodynamics states that the entropy of an isolated system never decreases, because isolated systems spontaneously evolve towards thermodynamic equilibrium—the state of maximum entropy.

Hm, seems like we need a "Jefferson's Law" (see the scrollover text) for software...

And Celine's laws... -- translate fairly well to organizational politics and architecture (esp. the 3rd)...

For me, xkcd is pretty much there:

"Munroe's Law needs to be submitted as a social rule where as XKCD's time running increases, The ability to relate a daily situation to the comic will approach 1." -- zerostyle

And of course, Murphy's Law.

Levity aside, what should I add? (Of course there's principles like SOLID: SRP, OCP, LSP, ISP, DIP; and DRP, PLS, SoC, ... and guidelines like YAGNI, and so forth. Ok, I've already argued that Postel's Law is really a principle. But what are the "laws" that software people would find useful, but are perhaps less likely to be aware of?)

As software goes, I really like that Jessica Kerr is helping us think about the distinctions between FP and OOP, and design issues that come up in FP -- on her blog, her tweet stream and her talks. Of course Michael Feathers is moving our understanding in these areas forward importantly too.

6/3/13: In his keynote at Ruby Midwest this year, Michael Feathers makes the case for "Deliberate Reflective Design" that is a call to use judgment rather than uniform application of standards and principles. This is very much in sympathy with our "extraordinary moment principle" which says "what at this moment is the most important thing for me to be thinking about?" -- in the large, it gets us to prioritize what uncertainties and challenges to address (for example, in this moment, what are the make-or-break market and technical risk/challenges we face and which do we go after now and soon?) and in the small it brings in all the factors that are flying in messy formation around what we are trying to do*, and figures out what the key drivers are and how to achieve them while also balancing and bringing into view factors/drivers that will rear their heads as key if we ignore them. Which really is the useful/adaptive role of checklists and standards and principles -- they should be used to bring what has been learned to bear to check how we're doing in this messy moment and remind us of some things we might, in all the demands on our attention, have neglected. In short, we shouldn't let our tools become our masters, but rather use them judiciously and art-fully. Further, while we are learning to master our craft, it is useful to attend to our technique and principles help us internalize values (and their tensions and sometime even contradictions or paradoxes) and develop our technique**.

If we look at moral values and moral principles we see the same sorts of tensions. If we tried to make everyone adhere to the same values and principles uniformly, we'd get a society that has little variance and poor fit to different tensions that arise in different contexts and individual situations. The film Anna Karenina is a great treatise. This doesn't mean that values and principles are bad. It just means that we need to allow that personal judgment and circumstance needs to factor. Too.

Dana, playfully but meaningfully, asserts that there is a silver bullet in software and it is "relationships of goodwill and a commitment to objectivity." (Let me hasten to add, in this cognitive/perceptual/decision bias/flaws -aware world, this doesn't mean Dana makes the assumption that we are always, and by default objective, but rather that we seek to bend our path toward objectivity rather than alllowing ourselves to drift away from it).

This (neat Serendipity, via Stuart Boardman) is pertinent:

'You know there are things, it’s all about balancing the kind of the rights and freedoms of individuals or small groups versus the — what’s the good for the whole, the common good. So there’s balance between individual freedom and the common good, every society has to figure it out, and every company has to figure it out. And I think what these large companies, one of the things that they have done is, they have been big enough to say “we are the ecosystem. If you want to collaborate, collaborate with us, the way we want to collaborate.”' -- Dave Gray,

(But applying the analogy at a different scope, to system and capability or component or algorithm.) We introduce (a minimal set of) standards, principles, over-arching or higher level design decisions, and such, (in the best case) to bring the "overall good" into the "local" picture of a narrowly scoped design consideration. But it is a factor to be weighed along with other factors. And judgment has to be used when we choose to put aside bigger systemic concerns and outcomes -- and we need to judge when to raise our desire to do so to the architect who is balancing more of the system concerns that are being tested and weighed locally. And so forth. Deliberate reflective design. Being more conscious of the factors that give design integrity and make for a sustainable design.

Judgement factors. As does experience. Ours. And that of others who work with us, and before us.

So, my heart is really in "no brute-forcing" -- no willy-nilly application of some principle on the simple basis that some guru said so; no filling a wish-list with every checklist, standard, law and principle we can scour off the knowledge stocks Google-Bing indexes and then living slave to them; yadda. But equally, the exhortation isn't to go cowboy in the city. The days in which Django Unchained was (ostencibly) set were wild and brutal survivalist days... Frontiers open up where many rules are an impedance to doing what makes sense. But in the city, wild bullets are going to take down innocents. And wild stuff like that. Sense. It gets tested a lot in this frail form we come in, but we still strive to have some, and to return to some form of balance where the contradictions within ourselves, and in our contexts, can be lined up enough that more good than bad stuff happens!!

* For example, we are juggling issues of conceptual "proximity" and (often algorithmic) cohesion with what prompts changes and hence what tends to change together, along with, for example, what is really uncertain and experimental, or complex and we want to shield the rest of the system from the special knowledge and care this piece requires, and and and multiple forces and considerations flying not in close, aligned formation so much as a messy interacting buzzing around what we are designing. Or something.

** I like what Michael is doing there -- specifically, he illustrates design challenges with examples that put the questions (or challenges) to which the SOLID principles are an answer/response before us in place of the principles. Notice that the questions/challenges require (even more) judgment -- they aren't pedantically didactic the way the principles are. And multiple challenges get thrown against the same posited structures, begging the question of which alternative best satifices the conjoint set of goals and properties/qualities we are striving for. (I feel obliged to mention that these questions overlap with questions*** we ask in our architecture workshop. I don't mean that in a "been there done that" way, for Michael does a wonderful/much better job of positioning them, and shades/nuances the approach in a way I much like/value! Oh, and I can't help teasingly pointing out that while he makes apologies for being abstract, I just let comfort with abstraction be a filter that sifts out the architectural thinkers. ;-) I'm teasing, but mostly myself. Architecture astronaut has barbs that are not lost on me. Even so... I deal in abstractions. Being abstract, making connections, drawing relationships. And making leaps. IS my game. Frustrating, I suppose, for those who... what the jabberwocky! Deal in abstractions. Name made up things. That have to relate. That shape shift over time. Oh. My. Cheshire Cat!

*** (6/6): These questions or challenges bring design heuristics into view, but require judgment in applying them because they don't prescribe what must be done in response (being both more open ended/not prescriptive but rather attention directing, and taking into account multiple simultaneous concerns the architect/designer is weighing and addressing), though they are suggestive.

6/6/13: Nice post today by mfeathers:

Image: Design questions and design challenges come up in many ways -- from the big questions and uncertainties in the market to the technical challenges in creating structural integrity (where I think of design integrity as both structural integrity and fit to context and to purpose). Image source: cjdelling via Jennifer Aaker

Which also reminds me to mention Charlie Alfred's work on architecture challenges -- which is on a different vein than collecting the set of general design challenges that are useful to address at our designs (alternatives under consideration or "legacy"/existing code). There's also the strategies and tactics work addressed at system properties (e.g. done by the SEI/Rick Kazman, etc.).

All these things wash together in messy ways. I was collecting "laws" and mentioning principles and responding to my inner goad that reacts against big anything and towards minimalist, so I riffed off the part of mfeathers talk that reminds us to use judgment. But having bought his talk in as a push-off point, felt I had to point out that his talk isn't about judgement in the large (which, important though it is, would be too wishy washy to fairly characterize the talk) but rather gets into specifics... Garr. I shouldn't engage. If I don't mention other work, I can be more of an idiot. ;-)

6/10/13: Scooped:

Goetz's First Law: "Its never any one feature that causes problems; it is the interaction of otherwise reasonable-seeming features." (via Michael Nygard)

Which recalls to mind this quote:

"Accidents can occur from the unanticipated interaction of non-failing components." -- Scott A. Snook, Friendly Fire

6/13/13: On uncertainty and judgment in engineering:

"Engineering, especially in fields which are developing rapidly, typically involves decisions made on the basis of incomplete data. The engineer works against rigid time schedules and with a well-defined budget. He cannot afford the luxury of examining every question to the degree which scientific rigour would demand. Indeed, "engineering judgement" connotes this ability, as well as necessity, to come to good decisions with whatever scientific data are at hand.

Sometimes the crucial data are insufficient for the engineer to proceed: the project then must await further scientific research. Usually, however, the engineer makes do with whatever data he has: he then uses the wisdom called "engineering judgement" as a guide. The engineer exercises his judgement, on the whole, by being conservative. If he is unsure of the "creep" behaviour of a new alloy, he will ordinarily overdesign his sections so as to withstand the worst conditions he can imagine. The extent of overdesign is largely determined by the engineer's budget: an important incentive for acquiring more data is the desire to avoid costly overdesign.

Uncertainty is in a sense inherent in engineering: unless one is willing to build a full-scale prototype, and test it under the precise conditions which will be encountered in practice, there is always the uncertainty of extrapolating to new and untried circumstances. Where the device being engineered is small, like a jet engine, a full-scale prototype is customarily built: difficulties are worked out either on the prototype or on the early production models. But where the device is huge, like the Aswan Dam, or a 1000-Mw plutonium breeder, or a large bridge, a full-scale prototype is out of the question. Moreover, the service life of such devices may be as long as 100 years : even if a prototype were built, there would be little sense in waiting until weaknesses appeared in the prototype before starting on the next model. Thus in every advancing technology there are inherent elements of scientific uncertainty which as a matter of principle can never be totally resolved."

-- Alvin M. Weinberg, Science and Trans-Science


Some Flaws to We Keep in Mind

One of my favorites is the book title You Are Not So Smart. Oh, I haven't read the book, although I've read the blog from time to time. No. I really mean the title. You -- are not so smart. The author, we should understand, is smart enough to write the book on You being not so smart. That is a recursive joke that I would expect the author invites knowingly. I hope so. Because while Nassim Taleb expounds on the virtue of self-awareness he seems to have little. I too have blind spots you can't see. All those you do see? Well, I see those too because you don't keep quiet about them, now do you? ;-) For example, you think that I am blind to the egoism entailed in writing a Trace in which I show up. Ha! (Wink) How dare I point to Taleb's overt displays of territorialism, when, in doing so, I fall foul of the same ploy? In essence, I'm as scrappy a street fighter, climbing the monkey power tree slinging... um. This is starting to sound like a Ze Frank True Facts episode... ;-)

Ok. Let's get serious. Some books:

Some talks:

And, if our cognitive baises could fail us, this would make sure we never make a decision with confidence again:

Some illustrations:

On the funny side:

What else should I add?

Hm, yes, this:

  • Emotional Intelligence: Why It Can Matter More Than IQ, Daniel Goleman (wikipedia says it introduced the term amygdala hijack though I don't remember that specifically)

and with applications (wink):

And looking up nucleus accumbens and leadership leads me to this:

Ruffyan moreishness:

Other moreishness:


I really liked Dana's positioning of ongoing dynamic strategy [stated as to an executive team, but not organization specific (you can stop shuffling your feet uncomfortably)]:

"One reason why so little benefit has [generally] accrued from visioning and strategy work over the last 30 years, is that it has been episodic, unpredictable and disconnected, rather than ordinary, rhythmic and woven into business functioning. Imagine that you only have access to your own careful thinking and wisdom occasionally, and unexpectedly. In between times, you know there is something important you’re supposed to be doing, but just what it is, isn’t quite clear to you, and even for the part that is clear, you’re not sure how to proceed. Then, all of a sudden, wham, your thinking is on steroids and all your life history and wisdom are present and functioning, you’re acutely aware of what you want to get done and of the relevant contextual forces, and you work with focus and energy to get as much done as ... Oh, what was I doing. It’s gone again. At first, you long for the arrival, but after a few cycles, you realize how these episodes disrupt your normal patterns, consume lots of energy, and are over before you have time to really get the value out of them.  

There is an important place for occasional big events. I think the Constitutional Convention of 1787 was just the right thing. But visioning and strategy need to be part of the ordinary functioning of this organization, 
activities we regularly engage in, 
with which we become familiar, 
that we tune and improve over time, 
that clearly influence our decision making and action taking,
and because of all this, we are more effective, integrated, ambitious and confident."

-- Dana Bredemeyer

Making All the Difference

Peter very kindly recommended my May Trace, and Alan retweeted the recommendation. One small tweet for man, a reassuring gesture for someone who needed it!

Kind words and deeds. They make all the difference.

6/3/13: I'm not always right. (If you read here much, you'll know that I write to figure things out, which means I often find myself wrong, and ammend myself. Sometimes quite radically.) But I'm not bland. And I try to take on meaningful topics. You may not think they are front and center important to a technologist -- until the beast is staring you in the face and you realize, damn, that Ruffyan idiot wasn't.

So if you say something encouraging, we are not going to think you agree with me. Given that even I don't. ;-) But it's nice when someone just is nice. It is rough being in a field where "wrestling" rather than "hugs" is the end all of how human contact is meted out. ;-)

I mean, you guys. Hello. Why isn't anyone saying this is frabjously awesome:

"To be sure, we don't have a crystal ball, but we can begin to resolve uncertainty by making decisions. We will have to adjust, adapt, amend. But if we don't start to see, and to move towards the future we see, we stand still, wrapped in inertia and uncertainty, or simply get bumped on the tides created by other people's more determined, concerted will and action." 

That "make it predictable by deciding" owes a lot to Dana. Sure, sure. Not 100%. But we have a better shot than if we do nothing,  We design, and lead, to make something that isn't already so in the world. No sure bets. Lots of imaginative leaps, assertions, decisions, building, and testing -- not just our code, but the assumptions our code depnds on. Hello. Hello. Brain treat!   

Ooooo this is perfect. You can go now. Or not.

So. Hey. Today I was called Jiminy Cricket. I took it to be a gentle scolding. But I could have let it be a compliment. ;-)

It takes courage to speak to and for others as artists do. As leaders do. Giving voice, standing up, standing out, risks being made a target.


The Architect Skills Workshop

A number of wonderful architects are signed up for our next open enrollment Architectural Leadership and Other Skills Workshop which is coming up in Chicago/Schaumburg on July 16-18. There are still seats available, and we would love to have you join us. Email me for more info: Ruth



Architecturally Significant

Architecture includes but isn't limited to just those decisions that are significant by the "cost of change" measure, but those that are significant to structural and design integrity and (competitive) sustainability (in the larger sense of economically viable now -- delivers value -- and into the future -- is economically and technically and environmentally adaptive and adaptable and suchnesses).

For example, it may be a "finer detail" but if it is going to percolate up to affect system identity or otherwise impact system integrity, there's some architectural work to be done to communicate what identity and integrity mean for this system, so that more fine grained/local (in scope of impact) decisions are consistent with the identity and don't undermine system integrity.

Let me make this more clear: I am not advocating architectural oversight of error messages!! (That's a wink to those who saw how this trace started its life.) That's so far from minimalism it's utterly absurd! But if a seeming small detail erodes the product/enterprise identity, and these things add up to something that impacts success, they are architecturally significant.

Culture and values get expressed through technical details like the state of the code and our conduct observable through the membrane of the system. And while culture is emergent from many factors, it can be influenced by the stance, the conversations and stories and attention, and so forth of the technical leadership.

More exploration of architecturally significant decisions here:

Um, I think I need to go do this now....

(Twitter has growing pains... We understand... And Twitter teaches us that eventually consistent can be very ... eventual when it comes to Twitter DMs... and we put up with it because we're addicted to it! Speak for myself? Ok. Ok. I'm addicted to it. But I was ranting earlier about the "Thanks for noticing" error message. Ever since I entered the Twitter world, that has irritated me because it is condescending. I mean. The world stops. And we get "thanks for noticing"? See what I mean? Condescending. Oh, you hadn't noticed that? Oops. Sorry!)

Um, I think I really need to go do this now....

6/4/13: Rats, this keeps happening to me:

"being quiet in short intervals because there's only so long you can be this excited about everything before it leaps right out of you..." -- Brian Andreas

See, this is perfect:


Perfect? For architecture -- deciding what belongs in the architecture is, no way around it, an architectural act.

I can't tell you which decisions should be in your architecture. I can tell you which kinds of decisions are likely candidates. I can give you examples of decisions and I can guess at and start to give you an idea of the forces and drivers and goals that were in play that made that decision an appropriate one for that architect to make.

But the corollary is that when the management team or the development team make a decision that is architecturally significant, they have become that system's architects and they may not have the perspective and experience to have brought in the appropriate mix of considerations and experience to bear, and they may not have the experience and the leadership weight to ensure that the right tests or experiments are done to validate the approach taken and and and suchness. I'm not trying to undermine and understate the excellence of managers or developers, but only saying that it does actually take time and attention and a way of perceiving and way of shifting perception and and and to make architecture/system design decisions that is similar to, but in important ways different to more local technical decisions -- like the conversations that are had are different when the decision crosses organizational boundaries. That overlaps with conversations managers have in terms of resources and tradeoffs, but is deeply technical (for technical systems). Etc.

There's no getting away from it -- developers and managers will make architecture-impacting decisions (sometimes even subversively)... But deciding what belongs in the architecture is, no way around it, an architectural act. Which has shades of political, because resources are managed in organizations in politically charged power structures. I'm not saying this latter is necessarily a bad thing. Resources are limited. Mechanisms will exist to channel resources. And the same essential mechanisms can often be used maladaptively and for ill, or adaptively and for good.


Oh My Goodness...

Alcohol has really taken to social media like ticks to my dog on a hike through the woods.

Mining tweets to find people who seem depressed and following them with a persona who spams gin and martini? That is sick!

6/5/13: Spam is getting ever more creative too. Got "invited" to CIOSummit -- which, you understand, never happens to me, so I did some Googling... Found this. Hm.



Thank You for Noticing?!

Is there anything more irritating than:

Twit! ("Thank you for noticing"???)

No, not the fact there is an issue. But the "Thanks for noticing". How can Twitter still be doing that? Because... no-one notices? Or is too nice to complain? Oops.

Word to the wise: when you shove an error message in your users face with nothing else to look at, don't say "Thanks for noticing."

In my interpretation of architecture, error messages are not architecturally significant -- until they are. And when they are really really good -- like the first unicorn -- or really really bad -- like "Thanks for noticing" this really obvious in your face thing we just did that stopped you in your tracks and you couldn't possibly not notice -- then... the architect should step under that arch. System integrity. It's architecturally significant if it can, or just did, #fail. ;-)

Say SORRY dammit. Just. Say. SORRY.

Ohhh. It's funny that we're thanked for noticing? Like, you pour a bucket of water on me, and expect me to laugh funny? Ok. Yeah. Ha. Ha.



Um, I think I need to go do this now....

Grok check: It may be a "finer detail" but if it is going to percolate up to affect system identity or otherwise impact system integrity, there's some architectural work to be done to communicate what identity and integrity mean for this system.


Oh yeah. If I messed up on how I read that and am being emotionally over-reactive, kindly let me know in an aside, so I can fix it. ;-)

Still... Nice of Twitter to let me make the point that architecture isn't just those decisions that are significant by the "cost of change" measure, but those that are significant to structural and design integrity and sustainability (in the larger sense of economically viable now -- delivers value -- and into the future -- is economically and technically and environmentally adaptive and adaptable and suchnesses).

It may be a "finer detail" but if it is going to percolate up to affect system identity or otherwise impact system integrity, there's some architectural work to be done to communicate what identity and integrity mean for this system.

Let me make this more clear: I am not advocating architectural oversight of error messages!! That's so far from minimalism it's utterly absurd! But if a seeming small detail erodes the product/enterprise identity, and these things add up to something that impacts success, they are architecturally significant. Clearly "Thanks for noticing" is not impacting Twitter's success.

Culture and values get expressed through ttechnical details like the state of the code and our conduct observable through the membrane of the system. And while culture is emergent from many factors, it can be influenced by the stance, the conversations and stories and attention, and so forth of the technical leadership.

Funny how the oddest things will prompt the most important insights to fall from my fingers.

Thank you for noticing.


[While we're on the subject of #fail that percolates up -- Blogger's failure to be seamless to google-identity-carrying citizens and non-citizens of Google's Empire further underscores said imperialism in a way that hurts Google loyalty. This is a global world, and we want those outside the Google Empire to be able to comment on our Blogger blog easily and without frustration and without having to join the Empire. In this case, it sort of lines up with Google's identity so ....]

Hey. So. Should I remove the rant and just sift out the insights? ;-)

Icky. Icky. Ranty. Bad Ruffy!

Me: I'm sorry!
Dana: You're sorry?!
Me: Noooo! I'm apologizing!

More exploration of architecturally significant decisions here:


Ok, I Don't Need You Any More, I've Found Bill (Or "Bill")

All I ever needed!




Here Comes Everybody...

Psst. Getting Past ‘But’:. There. That should do it.


Ok, ok. Back to doing this...

Maps. Because we couldn't possibly do anything called models. Been there. Done that. Got the jabberwocky kicked out of us. But Alice dressed as Agile slew him dead dead dead. So. Maps.

Ohhhhhh. It's all different now. Now it's Gamestorming. Psst. Many visual tools. Serve different needs. Call them what you like.

Captain Picard told me to engage.

So. Hey. What do you think?

The hipster cats out there are scary! ;-)

But they need... to get visual. And I knows how. Been doing Influence Maps and Context Maps and Stakeholder Profiles and Force Field Analysis and yadda for <cough cough> nearly two decades. Rats. Just blew my credibility.


Ok, ok. OKAY already. Back to doing this...

But... Don't forget Conceptual Architecture Diagrams and CRC-Rs (for factoring and refactoring responsibilities and keeping track of dependencies and the "What The Jabberwocky was I thinking" connected dots to the "why's" and and (and) past "WTJ's we learned from" aka experience and such). And and and. (Hint: two words: behavior; transformations.)

You're so very right. I do need to do this...

6/5/13: I like how Peter Bakker's Mapping book is coming along. :-)


6/10/13: Aw, I came back across this from 2009:

Sara asked me to "draw something, not just a stick figure." She wanted to see if I could still draw--I'm stung! But not because I think I can draw... No, I'm stung on Archman's behalf. Archman isn't (just) a stick figure!  He (and she) is a stick character. There's a difference. (I think. Maybe.)

Aren't you glad I kept trace of that, and (re)told you?

I... uh... also (re)read this. Hm.

Would it be minimalist to mention that everybody who goes rantishly superlinear on use not reuse of code chunks needs to remember that we use the re to (re)emphasize using it more than once? I agree that when I reread a book I read it again and when you read it (for the first time) you're just reading it; same book, read by many. But we're trying to (re-)educate people to (re)use code that has already been used once. Not minimalist? Why goodness me. Gosh. So sorry. (The other day, I said "sorry" and Dana said "sorry?" and I said "no, I was just apologizing." And he said "phew. Was gonna ask who you were and what you'd done with my wife.") I agree that use makes more sense. In a way. But I also understand why the emphasis of re is a useful, given the mindshift... Not minimalist. Uh oh. That'd be hard!

6/10/13: Two lovely papers (thanks Peter Bakker for the pointers):

Of course, I traced Barbara Tversky in 2009... ;-)

I've done a lot (and that really means a lot, coming from me) of writing about sketching and visual modeling/visual thinking/visual design and visual architecting (obviously) see for example numerous entries in the Trace from October 2010. But of course traces on the topic are scattered throughout. For example:


Lesser Talents? or Someone Had To!

INTERVIEWER: ... Now, the thing that interests me about this is that you are the only poet in America for whom there is any scenario, no matter how far-fetched, of actually entering into real political power. Is this something you think poets ought to do? Would you do it?

SNYDER: I've never thought seriously about that question. Probably not, although I am foolish enough to think that if I did do it, I'd do it fairly well, because I'm pretty single-minded. But you don't want to be victimized by your lesser talents. One of my lesser talents is that I am a good administrator, so I really have to resist being drawn into straightening things out. The work I see for myself remains on the mythopoetic level of understanding the interface of society, ecology, and language, and I think it is valuable to keep doing that.

-- Gary Snyder, The Art of Poetry No. 74 Interviewed by Eliot Weinberger


Cognitive Distance

There's this:

"The lack of observability endemic to production software is bad enough, but the layering of software abstraction makes the performance problem much more acute. Normally, software abstraction is good news, for it is abstraction that empowers one to develop an application without having to develop the Web server, application server, database server, and operating system that the application rests upon. This power has a darker side, however: When developing at higher layers of abstraction, it is easier to accidentally induce unintended or unnecessary work in the system. This is tautologically true: To be at a higher layer of abstraction, less code must induce more work, meaning it takes less of a misstep to induce more unintended consequences.

Unfortunately, this unnecessary or unintended work tends to multiply as it cascades down the stack of abstraction, so much so that performance problems are typically first understood or characterized at the very lowest layer of the stack in terms of high CPU utilization, acute memory pressure, abnormal I/O activity, excessive network traffic, etc. Despite being a consequence of higher-level software, symptoms at the lowest layer of the stack are likely to be most immediately attributable to activity in the next lowest layer—for example, the operating system or the database.

This presents another paradox: System performance problems are typically introduced at the highest layers of abstraction, but they are often first encountered and attributed at the lowest layers of abstraction."

-- Hidden in Plain Sight Improvements in the observability of software can help you diagnose your most crippling performance problems., Bryan Cantrill, 2/1/2006


and there's this:


BC By raising the level of abstraction, you make it easier for things to be correct by inspection.

AW Yes. I have about 1,000 customers around the world in different banks and hedge funds on the equity side (where everything's going fine). I think the ratio of comment to code for them is actually much greater than one. I never comment anything because I'm always trying to make it so the code itself is the comment.

BC Do you ever look at your own code and think, "What the hell was I doing here?"

AW No, I guess I don't.

BC Wow! I confess that I tend to write comments for my future self. I know that when I come back to code I've written, I often don't recall instantly what the problem at hand was or how I solved it. Now you've got me thinking that maybe I'm just in the wrong language. When you're at this higher level of abstraction, maybe it's easier to see your intent. In terms of debugging your code, obviously the power of a terse language such as K or Q is that, presumably, it's easier to find bugs by inspection. How do you debug them?

AW In C I never learned to use the debugger so I used to never make mistakes, but now I make mistakes and I just put in a print statement. K is interpreted, so it's a lot easier. If I'm surprised at the value of some local at some point, I can put in a print, and that's really all I do.

BC That works well when you have deterministic inputs. What if the nature of the problem is just less reproducible—for example, if you were in an event-driven system where you had a confluence of events that led to a problem?

AW It has been 20 years now that I've had Wall Street customers—they're doing 2 billion transactions a day and they have trillion-row databases—and in those 20 years, there was one time where we couldn't reproduce the bug. That was nasty. I knew the kinds of operations that they were doing and I finally found it by just reading my code.

-- A Conversation with Arthur Whitney February 1, 2009 (BC is Bryan Cantrill)

But wait:


6/6/13: Nice add to the equation:

Those of us who majored in math, studied and practiced computer science, and any of the other fields that rely heavily on applied math, know that notation and the "grammar" of mathematical language is a powerful cognitive lever. We also know that it is dense and impenetrable to a newcomer to the problem space and even more so to the newcomer to the language space. (The number of errata indicates the difficulty even for the steeped expert in a channel of thought.) It takes concentration to construct and to parse. And to hold more in mind that the details, we rely on a conceptual partitioning, however we designate it. So we're juggling grokability and communicability, and conceptual manipulations at different granularities, and all or nothing kinds of approaches leave some cognitive gear off the table.


Blindingly Obvious that Blinds

An innocent response (by email) to my Architects: Flexibility and Dots to Connect blog post threw me into one of those crises of self-criticism to which I'm overly prone -- I immediately saw the points I made especially in the opening, as completely trite and inane. Heck, if we didn't learn from books and others, why go to school? University? Why scour the internet? All the people saying "Just Do It" in blog posts are expecting us to READ their exhortation to get on with doing rather than reading. And so forth.

Then again, once we leave the required reading of University -- which in many degree programs has very narrow tunnel vision -- how much do we read? And how diverse is that reading? Do we allow ourselves to believe that reading poetry or going to an art gallery has any touchpoints on our development as architects?

So I think the post is useful in spirit, but could be improved by pointing out that most of us give up drawing by 8 or 9, and our reading starts to tunnel in and focus as we pick out a career. And the case needs to be made that it is career critical for people who want to make meaningful products and otherwise design and innovate to have these diverse feeds into our minds.

We learn from all of our experience, including the experience of engaged reading. And important as it is to develop deep expertise, diversity in our thought lives comes to play a surprising role we can't a priori predict or specifically prepare for in a world that presents surprises, complexity and change. So developing empathy and flexibility and imagination is an adaptive response to our organization's needs for innovation and (anti-fr)agility.

That's what I don't like about a blog! I want to go in and edit what I learned. That aspect of blogging is badness for a me who writes to learn. [I do other things to learn too, like reading. Just testing which box you put me in. Yeah. I thought so. ;-)] Then again. The engagement that caused a person to innocently and generously make a different point, but which prodded this realization loose, is the wonderful up-side of blogging.


6/5/13: Do this: Look at the red dot. It is amazing! What the brain can do. Just. Astonishing.

6/5/13: Serendipity is an amazing creature. (Our brains are ever so good at noticing what we just noticed, and other pattern matching, but still...) Earlier this morning, I pointed Andrea to a trace largely on sketching, despite it's Architecture Principles title, in which I quote:

"Tell me and I forget,
Show me, and I may remember.
Involve me, and I will understand."
-- Confucius

Then, because my point about learning (second-hand) from wisdom passed down by the greatest but also lesser known minds of the great parade of human history is being made not in opposition to, but in company with, experiential learning, I took a look at (via Peter Bakker) Experiential Learning ... on the Web by Tim Pickles, which, right up front, quotes, wait for it:

"Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand."

The way I involve myself in what I read, is by arguing with myself over it. I'm not going to show you my marginalia. :-) But it is fun (re)reading Youdon and Constatine's Structured Design (after Kent Beck tweeted it, I had to go back to it) and reading the young Dana Bredemeyer's responses to it from so very long ago. :-)



What's the Big Idea?

I really liked Stuart Boardman's Mr Ashby’s Bright Idea post. Yes, he committed a first: "Ruth Malan’s requisite flexibility principle." And while I think it is the mark of a great man to read any of my* work (mischievous smile), it is a useful exposition and discussion of Ashby's Law of Requisite Variety. It is not the same-old regurgitation, but a probing curious discussion and well worth reading. Eager for the rest of the series!


* Aside from the enormous tolerance it takes to look past all the icky-icky me-ness of my traces, it also takes wisdom to get past the caskets of stereotypes and downcasting that we too often, not even consciously, stuff those who haven't been sanctioned and vetted by the dominance credit bureaus of publishing houses and conference circuits into. That's a huge big WINK. I playfully kick at the tires of our beloved institutions, and challenge us to consider our fallibilities (including my own follies and vanities). But at the very same time I do value the role they play. I just think we need to build a more plural world, where it doesn't just take strong-handed dominance posturing to survive and thrive. Anyone want me to keynote this at a tech conference? WINK! Sorry, my sense of irony is kind of skunkish, isn't it?

6/7/13: Perhaps I should note -- the point to which Stuart alludes is only tangentially made in the blog post itself. It is made in this Trace, and has various antecedents in other traces. I made it specifically in a comment on the Flexibility post that I deleted, and added back in after I'd removed an uncareful-playful concluding "goes beyond Ashby" ego-marker that was inappropriate (for anything less personal and informally playful than this Trace). :-)

In my introductory characterization of my Trace in October/November/December last year, I said, among other things (you should read the December intro, it's that good*):

This is my "platform for change," where I develop (and share) flexible variety / requisite flexibility necessary for designing and enacting complex systems

If you are a Stafford Beer fan, you know what Platform for Change refers to. Impish wink. Yes, it is his book where he interweaves more personal and informally -- poetically -- expressed and more formal observations and explorations (but with color coded pages, to enable avoiding (huh?) the informal, or (yes!) one could go through the book following different veins through it).

You would have to understand that my view of complex systems is nuanced by the ever changing nature of change in a competitively evolving, ecosystem disrupting, world. Systems change and are changed by their contexts in dances of evolutionary change. Dancer-like flexibility is a lovely image, especially when you understand how quickly ballet is evolving in response to changing audience tastes and a kind of attention deficit disorder that requires diversity of experience and surprising surprises... ;-)

More related traces:

6/7/13: Flexible variety in Nature:

"The popular understanding of DNA as a blueprint for organisms, with a one-to-one correspondence between genes and traits (called phenotypes), is the legacy of the early history of genetics. The term “gene” was coined in 1909 to refer to abstract units of inheritance, predating the discovery of DNA by forty years. Biologists came to think of genes like beads on a string that lined up neatly into chromosomes, with each gene determining a single phenotype. But, while some genes do correspond to traits in a straightforward way, as in eye color or blood group, most phenotypes are far more complex, set in motion by many different genes as well as by the environment in which the organism lives.

It turns out that the genetic code is less like a blueprint and more like a movie script, subject to revision and reinterpretation by a director. This process is called epigenetic modification (“epi” meaning “above” or “in addition to”). Just as a script can be altered with crossed-out words, sentences or scenes, epigenetic editing allows entire sections of DNA to be activated or de-activated. Genes can be as finely tuned as actors responding to stage directions to shout, whisper, or cackle.


The long-running debate about nature versus nurture takes on a new complexion in light of this emerging understanding of how epigenetics affects organisms’ form and function. The boundary between nature and nurture turns out to be rather porous."

-- Nessa Carey, The Genome in Turmoil, Uncertainty in Nature

Fascinating stuff!!!



It's So Much Like Actually Being There ;-)

(Zats a grin). Distilled nugget awesomenesses:


Raising Nerds

No-one. No-one. No-one has asked for the next Sara story. What is with yawl? Oh. Right. It would be weird, huh? Well, this one is too good not to share. Sara is copy-editing her friend's novel. Here are two of her choice edits, with her accompanying comments (I anonymized the friend's name with x's):

Edit on: ' .'

That space is a rebel, Txxxx. It's not going to listen to all the other doormat spaces who decide to submit to what's expected and await their turn after the period. This little space knows that its time has come, and its time is NOW, not after the periods. Good for you, little space. Following your dreams. (no but seriously, the space and period are swapped right there)

Edit on: 'She is' (advocating she's)

Txxxx, Txxxx, Txxxx. Those two words OBVIOUSLY want to be together. Why on earth are you denying their love? Are you against contraction rights! Are you being closed-minded to what would clearly blossom into a beautiful romance? Shame on you, Txxxx. Let them be together. It's all they ask of you. (Make it. A contraction. NOW. We're all judging you, Txxxx. Who are you to say these wonderful youths shouldn't be together? You disgust me.) 

My daughter, the comedian. Move over Ellen Degeneres!

My son? He's awesome too. After just a few weeks of road biking, he has already completed his qualifying training miles and is well on his way to being ready for his border-to-border 1,500 mile cycle tour this summer. Last Sunday he couldn't make the afternoon training ride with the youth cyclists, so went out in the morning with the adult group and did 60 miles at their 20 mile/hour average pace on the very hilly back roads.

6/8/13: PS. I just wanted to say -- Sara's latest song is awesome. :-)


One-stop Requisite Variety Shop (reprise)

Do I lose or gain credibility when I quote my daughter in my Architects Architecting Architecture Trace? Waaat? Did I not do a thoroughly persuasive job on the Requisite Flexibility thing? Enough to justify any tangent? Hey, this is how I positioned my Trace in July 2012:

By way of orientation, let me add -- given the range of factors, the complexity, uncertainty and challenge, that the architect deals with both technically and interpersonally/organizationally, I believe that sufficient variety or requisite flexibility (or, if you prefer, the Ashby term requisite variety) has to be brought within the architect's compass. That gives me great latitude in terms of where I explore and what I feel is fit to be Traced here.

If you are new to this Trace, you have only your fellows to blame. I have been doing this for more than 7 years. And four or five people have mentioned it from time to time. The rest was up to everyone else and they failed us, didn't they? ;-) [It could happen... that falling upon my Trace, someone will chortle in their joy "O frabjous day! Callooh! Callay! ... and wonder why it is such a well kept secret. While we of course know better. There be strange creatures down that rabbit hole. ;-)]

(Requisite flexibility is flexible (requisite) variety, or the ability to change what variety we present. Thanks to Stuart for making me stand still long enough to pin that down. ;-)

Organizations -- even the giants -- have to learn to dance, and they only dance if we who make them up can dance gracefully and in patterned co-ordinated (sometimes even, in a sense, choreographed) harmony in places, and in jazzy improvisations in others. And other metaphors. Sara's latest song is about metaphors. How cool is that synchronicity?

Later: Wait, wait, wait. I've got it. But let's see what you think. Since there are like 3 people who let on that they read here (brave, generous men those!!), they shall have to shoulder the entire burden of buoying my self-worth with an occasional moment of effusion, and schedule themselves to deliver a surprise compliment once every three weeks. That's not too much to ask is it?

I'm joking. It is really too bad that the person who says wonderful things about my writing undermines his credibility with me by never being interested enough to read my Trace. And some of those who stop by habitually, don't say anything, so I assume they use my Trace to goad their thinking, kinda like one uses the wall in the swimming pool to push off when doing laps... But somewhere in this big world with ever so many people in it, there's got to be someone who'd think "O frabjous day! Callooh! Callay!"... No? Gosh. I'm so disappointed!

If we get no reflection back, are never met with a nod or a smile of delight, the mirror others hold up to us, tells us we are invisible!





Ooo, another:


6/8/13: Usually I feel pretty ok snipping people's tweets and pasting them in this Trace for safe keeping. :-) By ok, I mean that it is safe to assume the persons in question will be more pleased than not to have me draw attention to their points and to preserve them outside Twitter and the ecosystem(s) that has(ve) developed around Twitter. Placing them, as I do, in a context where they are appreciated and conversed with, and such. Hopefully... But... Sometimes... Well, taking that "don't ask for permission ask for forgiveness" approach that is the software developer/architect's golden rule -- oh, not The Golden Rule which we measure others by; but the golden rule we actually use. ;-) [You know, the one that says "they'll never know if you don't ask; duh." I guess it is some sort of corollary to the law that Parkinson's Law is a corollary* to... the dual of which might go along the lines of "what we are paying attention to shapes what we perceive and pay attention to" or something like that... Which law is that a dual to? You know, the one I haven't named yet. Ask Stuart to pin me down on it. ;-)]

The internet delivers:

"I suspect this book is a metaphor for war, but it also captures perseverance very well. What it takes to move past anything is to simply realize that your obstacle is unimportant, and that it can be dismissed. This is true whether you’re running a marathon or trying to get to Mars.

If you dismiss the things that do not matter; if you remove those things from your mind and focus on what must be done; if you understand that your time is limited and decide to work now; only then will you be able to get to the finish line. Otherwise, you will be dissuaded into living a life you aren’t interested in."

-- The Complete Guide to Not Giving a F**k

Don't miss the animation at the bottom. Because.

* at least in the case where busy well-intentioned people (who want and like to help) pay attention to the trivial thing they can make a contribution on easily, rather than the more urgent complex thing that they have no clue how to tackle and know it would keep them from doing the more obvious, simpler tactical things they (think they) know must be done. ;-)

Picking up the fallout from the lonely battle to be a human being and making the best of my own becoming with it.




Dana saw a young skunk doing circles on the road and pulled over. It had its face stuck fully into a yogurt cup. Dana whips out his phone and takes a video snip. A woman pulls up and says "Can't anyone do something?" And Dana says "Are you brave enough?" And she says "Yeaaaah!" in that "pfft, of course," sort of voice. And gets out of her car, still on her cell phone, and takes hold of the cup (still on her cell phone), and the skunk dangles off it for a moment then plops off and scurries away. While Dana is feeling about | | small -- and wishing he'd caught the whole thing on video!

See. Architecturally significant! Waaat??? Hell if I know, but I'll get Dana to upload the clip to Youtube and I'll put it on the Requisite Variety blog to see what lessons we can draw from it. ;-)

Smile! The jabberwockies we have to battle in architecture are (mainly? for the most part? more often than not? pretty often?) perceptual. And I don't just mean the icky-touchy-feely ones. The technical beasties are so much about categories, and analogies (this mechanism is analogous to this mechanism we designed in this system over here, and that idea came from this combination of analogies we drew from nature (yesss! hiss!) and and mechanical systems and...) and touchpoints and which skunks we can grab hold of and when... I mean...

Do not underestimate a lady ... with a story. ;-)


Funny. On June 5, I, for the first time ever, characterize my sense of humor as skunkish. And lo and behold, serendipity serves up a skunk for June 8's humor moment. How cool is that? The world just revolves around me, doesn't it?

Your cognitive disability moment served to you today by the makers of the Architect Skills Workshop. It's just like Red Bull, and you don't even have to jump out of an airplane to fly without a parachute! Wanna come? For a mere $1800 you can have front row tickets to 3 days of... Oooooohhh.

(Well, there are a few seats left. Better snatch em up fast!)



Moral of the story: And you guys are worrying about women driving while talking on their cell phones. Really! This woman saved a skunk without even breaking a sentence.



All the points are great, but I especially value this:

"3. Build the right software abstractions.

MIT Professor Daniel Jackson captures the importance of software abstractions well [7]:

"Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make."

Part of what allowed thousands of engineers to build scalable systems at Google is that really smart engineers like Jeff Dean and Sanjay Ghemawat built simple but versatile abstractions like MapReduce [8], SSTable [9], protocol buffers [10], and the like. Part of what allowed Facebook engineering to scale up is the focus on similarly core abstractions like Thrift [11], Scribe [12], and Hive [13]. And part of what allows designers to build products effectively at Quora is that Webnode and Livenode [14] are fairly easy to understand and build on top of.

Keeping core abstractions simple and general reduces the need for custom solutions and increases the team's familiarity and expertise with the common abstractions. The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems. Funneling the team's focus onto a small number of core abstractions rather than fragmenting it over many ad-hoc solutions means that common libraries get more robust, monitoring gets more intelligent, performance characteristics get better understood, and tests get more comprehensive. All of this helps contribute to a simpler system with reduced operational burden."

-- Edmond Lau, Quora Engineer (via mfeathers)

Oh yeah. I wrote trace on Software Abstractions (that uses that same Jackson quote, as it happens).



"Requirements" as Design

This is from a trace I wrote in 2007:

One other flaw in much of the "we must respond to a changing world" thinking is that it neglects our impact on the world. We aren't mere windsocks responding to the direction of the wind. We make wind! We change the course of history, in small and big ways, with what we create. We change expectations about what is possible. We interact with destiny, don't just simply bow to it. Though, to be sure, we ignore these forces at our peril. But ignoring our role in shaping expectation, shaping the world into which our systems will fit, is just as one-sided as blindly expecting users to force-fit our product offering to their needs. The world of pragmatists is the world of balance, the world of tradeoffs. This is just as true for the process we adapt to fit our needs as it is to the products we generate thereby.

It occured to me, prompted by reading this:

"But what’s more difficult to get a grasp on is the impact that concepts and ideas had on our progress."

that ideas can be "bicycles for minds" too. They can rachet up what we can create, and what society is capable of. In small ways. And big.

Then I read this:

“Words Matter” and “Ideas Matter”

Things begin as ideas. Things come of combinations of ideas and acts of building, which are influenced and shaped by ideas. And these ideas are acts of imagination and analogy or transference, of imaginative novel combinations addressing imaginatively conceived purposes that didn't exist in exactly that form before we begin to shape the purpose and the conceit of the thing that fits that purpose.

Gene Hughson wrote a nice post on tradeoffs (and the discussion in the commentary gets into technical debt as a case in point):

When I read that post, this one came again to mind:

Of course, this too is related:

And, drawing the thread that has wound its way from requirements as design to tradeoffs (which mean that we need to keep the "requirements" side of design in active suspension while we explore to understand the design tradeoff envelope better by getting into enough of the structural and mechanism design, and prototyping, even sketch-prototyping and pretendotyping, and incremental buildout of cornerstone mechanisms and capabilities and... you get the point) and back to requirements as design. Which leads me to mention my post from last month, that does a bit of a round-up of a few of my traces related to requirements as design. :-)

Yes, there's generally a thread of reasoning. It might be or seem pretty tenuous, but... suspension of disbelief lets art its do magic. ;-)

Negative space is wonderful stuff. Abstraction. Metaphor. Occlusion and elusion. Allusion. Suggestion. Connections. Associations. I have this wonderful slideset. If you get permission, you can use a limited number of Eschers in a keynote, but you can't put it online. So I need to create some alternatives. Ha. Yeah. Alternatives to Escher! Me? Sure. Smiles! [Hey, I can do mobius strips in words. Worship me! (Oh come now. Hyperbole! A bit of admiration now and then never hurt anyone. Did it? I wouldn't know, you see. But I don't see any admiration-damaged peeps... barring those who admire themselves... Oh shoot. This didn't go where I thought... it would. Where I thought it was going was to The Point. Which? Let's see... I wouldn't know... yeah, because our life is a longitudinal study; hypotheses and tests repeated ad infinitum until, like other empirical scientists, we get the answer we were looking for... Er. No. That wasn't... I give up! ;-) ]


Le Sigh

This keeps happening:

Dammit! ;-)

And this (but not enough! :-)

Ok. I need to go write a book now.

I'm soooooo sick of silence*. I need to go make some noise. ;-)

(If you find me back here, boot me off!)


* Ever so grateful to the few people who do engage in comments, email and such. I mean in a much larger sense. If this Trace doesn't spark enthusiasm, and if I want sometimes to feel like what I write lands, then obviously I need to put my writing moments into a different forum and format. I'm going, I'm going. I just didn't want those who have been kind to think I don't value their support.



Missing Me?

Then (may I suggest you) read the traces from March 2011. :-)

And really, if nothing else, isn't this worth the price of admission:

The visual design wave of the 90's gave way to the Agile wave of the last decade. Now managing debt is catching some of the refracted limelight from (fr)agile. Hype engenders zeal. Many overdo and hit the wall. We course-correct.


"Everything you know is wrong." So from time to time, open up your reading window to something different. My Trace is... different. In a good way! ;-)

Oh. For those who are relatively new here, this is my pattern. My system seems to need to crash (a little--just enough!!), to resurrect itself in defiance in order to do the next big audacious (frontier forging) writing thing. :-) [It's an adaptive process, like making room for new thinking, staying humble and on the watch for flaws, yet confident of my perspective and ability to push our conceits forward in useful ways.]


Leading Well

OMGoodness! In the "be careful what you wish for" category! I am seriously stunned and amazed! That left even my internal voices speechless for hours! :-) I'm unabashedly the chief cheerleader in Grady Booch's fan club -- he is, afterall, a pre-eminent father of Visual Design in software! And I'm very excited about Grady and Jan Booch's Computing project, because he is a great storyteller and sense-maker who will bring wisdom and perspective to computing's history and to considering what technology portends for humanity. But to be mentioned by him in a tweet with "wonderful" and Alan and Rebecca Wirfs-Brock... that... well I still don't know what to say.

I suppose trading humorous mock-insults would be more comfortable for all concerned in a scenario like this. But the truth is, I'm touched by the generous inclusion and humbled to have my name in the same tweet as the Wirfs-Brocks.

So, for future reference, what would have been an appropriate response? I was totally floored!

Well. Back to book writing! ;-)

On my way out(side, to dance with Life), let me just point out that Jessica Kerr is facilitating some very thought-provoking tweetversations on software design.

"Well in [a] free culture, you get what you celebrate." -- Dean Kamen



Missing Me?

Here's a little something for you:

Now you can go back to the traces from March 2011.

October 2010 was awesome too, ;-) Lots about visualization. And more.

Be a little bit excited about my work, would you? Sheesh! ;-)


UML is a Language -- We Choose How to Use It, When, and How Much!

From October 2010:

a sea of classes in a class diagram is still [generally speaking] an intractable medium for reasoning about and making architectural decisions -- decisions about resilient system structures and mechanisms that address functionality and cross-cutting concerns, etc. We need higher level abstractions, and we begin with conceptual entities, and elaborate and reify these in abstractions supported by our programming language and development framework...

...the UML has made a huge contribution to our field, but we do have to use it effectively! Think about it -- do we blame english for what people do with it? We can say it is expressive and provides the medium even for a rule-breaker like ee cummings to create great work. But we don't blame language for naive or inappropriate [or excessive!] use thereof! Nor has English been, and nor do we expect English to remain, static and unchanging. And we should expect this to be even more the case with a modeling language that supports a field that is as young and fast-changing as software!

-- Corralling Still More Thoughts Inspired by "Why Don't Developers Draw Diagrams?"

Just because UML allows us to represent a great deal of detail, doesn't mean we have to. Just because there is tool support, doesn't mean we can't draw sketches (on whiteboards -- who knew?) of the models using only just enough of the language. We can even break the rules of the language orthodoxy -- if we want. Then we can add detail; we can take advantage of tool support. If we want; if our situation is more (organizationally) complex, if we need more precision in our designs, etc. But we can use just enough, with the degree of (in)formality as fits the moment we're at. Judgement. It factors. Remember, the R in aRchitect -- it stands to reason. Models help us reason. And we reason as much as is reasonable.

Poets don't throw their hands up at English and say it's too much. Too Expressive. Too hard to learn.


Sorry. Something was wrong on the Internet.

Ooops. Back to...

Oh, since I'm here. Sara recorded two songs in the recording studio today. She is AMAZING!! First time in a recording studio and a real pro. Confident. Holding her ground on her artistic chocies. Just stunning. Kids these days.

6/14/13: I suppose I should note that I/we took liberties with UML. I do that with english too. :-) Essentially my approach is that when we start out, we haven't decided what our elements are, even conceptually. We're just mucking about with ideas for how the system might be organized, toying with ideas for structures and mechanisms, and playing out how different alternatives might work, in as fuzzy and fudgy a way as suits the moment. But we start to tighten down our thinking as we make choices, and as our design thinking matures (meaning we make more decisions and the jell starts to be more viscous) we start to use more of the modeling power and more support from the tooling. As we build out capabilities (internal and user facing, prioritizing using judgment), it is useful to have support (in tooling) to show us the shape of the system and show us where the design in the code is departing from the architectural design so we can probe why and if this is a good thing, and so forth. Our tools must not become our masters. But we shouldn't throw out babies when they soil the bathwater. They do that. We learn. They learn.



For The Incorrigible Optimist (Who Checked Back In On Me)

Reading here: totally a brain upgrade. Right?


Riiiiiiiight?!!! ;-)

And from my daughter's timeline:

Yep. Douglas Adams would no doubt have enjoyed ze Sara.

You unlocked doors in my mind, let jubilate winds in



Some Pebbles

“To dare is to lose one's footing momentarily. Not to dare is to lose oneself.” ― Søren Kierkegaard


Some relationships are simply beautiful gifts -- a tipping of loveliness into us, inspiring us to our best becoming.


I gave gifts of myself, stories letting fall a sparkling dew of insight.
I looked for a tenderness, a smile of welcome. Met only silence.


The Awesomeness that is Dana

The kind of things people say about Dana's workshops:

  • "Dana did a fantastic job engaging the group and demonstrated his knowledge and expertise in a very consumable way."
  • "With the prior work experience that the instructor had, it was helpful to get his first hand knowledge from his experience as an architect"
  • "This training left an impression on me that I will take with me throughout my career. I have already encouraged others to consider this training when it becomes available in the future."
  • "It's very unconventional learning with no slides & hands-on which is very good."
  • "Outstanding course."
  • "Dana did an excellent job in presenting the material. It was refreshing and effective and this kept me engaged."

Wahoo -- despite weather delays, Dana still made his connection so can get home tonight.

(As for the awesomeness that is my kids, my son is gearing up for his 3-week 1,500 mile border-to-border cycle, and my daughter for her several week ballet camp at a prestiguous ballet school. And she gets to go back to the recording studio tomorrow to record more of her songs. The hardest thing about being a mother, is letting the kids go off and do these amazing things -- so far away. Punishing hard. Dangerous. And character building.)

Listening to The Main Squeeze while I wait. Love Eyes of the World ("Sometimes we live no particular way but our own") -- perfect thing for tonight. (The Main Squeeze is our favorite local funk/jazz funk band. They're awesome!)



Some Pebbles for Father's Day

“It is hard to translate, but I think it means that people make the world come alive for each other.” - @brianandreas , Songlines of Chicago

"You were Real to the Boy," the Fairy said "because he loved you. Now you shall be Real to every one." -- Margery Williams,The Velveteen Rabbit

I want you to be wrapped in gratitude that you are here, in this awful-wonderful world

How is it you can see through me, and still admire me?
<smiling> Well, what I see through you is so much the more beautiful!


Image: Just pointing out one amazing Dad! :-)

Happy Father's Day to all you wonderful, generous dads who work so hard to make your family happy!


Later: This video about the love of parents, the love of a father, moved me to tears (via Maria Popova). Society has come a long way. This TEDMed talk can take us further!


Dana's daughter:

And ze boy, before heading off on a 92 mile ride last Saturday (don't worry, the helmet's just not on yet):

Dana Bredemeyer is an awesome husband and wonderful father to our two children. :-)



In response to this tweetversation, it is on the tip of my fingers to quote from and link to my Fractal and Emergent (F&E) paper:

'design thinking is in, and IT is “it.” But only for a moment, because the game of tag is obsolete'

This is the larger context for those phrases:

In short, design thinking is in, and IT is “it.” But only for a moment, because the game of tag is obsolete, and IT is a key player in remaking this baton-passing game into one that is less industrial-mechanical and more organically connected, technologically enabled, yet human-centered.

IT is at center stage because our organizations are inherently systems of socio-technical systems. A social system has inertial forces all on its own but compound these with interweaving of technology in the social system and the mass can be as immutable as reinforced concrete. We might see the enthusiasm with which service-oriented architecture (SOA) was greeted as recognition for the need to flexibly bundle, unbundle, and reconfigure bundles of organizational capabilities, without bringing down and reengineering widereaching organizational systems. And this is a step on the path to agility — an important one. But it has to be coupled with other changes, foremost of which is embracing design thinking not just in product development but IT, and more broadly, the design of enterprises, and EA.

-- Ruth Malan and Dana Bredemeyer, The Art of Change: Fractal and Emergent, 2010 

This, from earlier in the same section, sets the scene:


What does this all mean for IT? Products, services, and solutions are what we offer customers, but behind those offerings is a web of value anticipation, creation, and delivery. A modern enterprise is an extraordinary network of intelligences and actions — human, compute assisted, and digital or digitally controlled mechanized actions. Technology is what we solidify business capabilities around to increasingly optimize within a competitive paradigm. More work is shifted from people to digital technologies, processes become more woven into the web of software solutions that support them, and the business becomes deeply embodied in technology — and technology deeply embedded in the business.

IT Lands a Leading Role
We have observed that the meaning of business is shifting in the direction of more complex relationships within and across organizations, allowing for the creation of synergies to produce new kinds of value. Many of the business capabilities that IT supports and enables have to do with building and maintaining relationships and their information spaces to run the business and create strategic advantage. These relationships include supply chains, distribution channels, and direct customer relationships; design agency, formal media, and social networking relationships leveraged to build brand identity; product development networks, including key suppliers and customers (in the Outside Innovation sense); product support networks; subcontracting, outsourcing, and vendor networks; and so on. They also include internal networks organized around traditional functions as well as workflows and around achieving cross-organizational synergies such as those that form around cross-selling products or services.

Relationships, both formal (with codified transactions) and informal (with dynamic, even ad hoc, interactions), are enabled through high connectivity. [...]

[...] A unique role that IT plays, though, is providing the means to interrelate entities and capabilities, along with their information spaces, to create leverage and reap synergies to make the organization more than the sum of its parts. Creating a “relationship platform” for the business in the context of the diversity of technologies, solutions, and micro-cultures, which is the heritage of the dominant “divide and conquer” organizational design mindset, is a nontrivial yet highly strategic undertaking. [...]

[...] Turning our attention to information, we note that operational excellence, customer intimacy, and market response speed each demand excellence in information husbandry. Both the information and the capabilities associated with transforming data into business enabling intelligence are prime areas for developing cross-organizational synergies. [...]

[...] When we recognize that this is a world where organizations increasingly compete on and for relationships, perception, and fidelity, and on information leverage, the strategic role of IT jumps into sharp relief. Place this in a context of change, and IT finds itself with a leading role on the strategic stage. Whether it is playing the role of the proverbial bad guy responsible for runaway costs and change encumbrance or a partner in a landscape-defining dance of change depends very much on how well IT is integrated into strategic decision making — at various levels in a fractal approach to strategy setting.

-- Ruth Malan and Dana Bredemeyer, The Art of Change: Fractal and Emergent, 2010 

Don't you just love the drama. IT has been cast -- in a leading role. Swoon! ;-)

Also related:

The F&E paper is relevant and useful, yes? The innovation and ecosystems model (covered in that paper) is like awesome, and all. ;-) And it is very much about the relationship between IT and product innovation. And more. More more. It's, you know, short book-ish. But free (almost -- it does cost your contact info but that's less than the usual price of a book for which you have to give your contact info and your address and credit card number. ;-)



Shoulders We Stand On

(Yes, I put mine in there too, but please note that I stand on shoulders too -- yours even. :-)



Creation, Metaphors and Myths

Serendipity and Bliss (or a curious conspiracy of coincidences) have served me up an interesting mix of reading the last several days. Into the mix, there is also someone saying, the other day, that when he was in Manhattan he looked around him with the staggering thought that everything he was seeing began as ideas. The whole world that is Manhattan, was created first in conceits of mind -- thoughts then actions, some concerted at least in some endeavor, making manifest a world of physical and social/cultural marvels.

So, (depending on where I was over past few days) I've been (re)reading George Lackoff's Metaphors We Live By, Douglas Hofstadter and Emmanuel Sander's Surfaces and Essences: Analogy as the Fuel and Fire of Thinking, Joseph Campbell and Bill Moyers The Power of Myth, and Richard McKenna's Fiddler's Green. Interesting mix, part intentional, part (drums fingers ominously) synchronicity. ;-) You want to know what I made of the mix, and the individual works? Well, I'm going to treat that as rhetorical. ;-)

Since I haven't been tracing, just messing with pebbles ;-), I didn't tell you I woke from a dream the other night with one impression so strong it emphemerized* any others that might have accompanied it out of the dream... And it was that I was writing a book called "Your Product is in a Family Way; Now What?" That's a book that needs to be written, don't you think? ;-)

* not emphemeralized. That's different. I need to put Nine Chains to the Moon on my stack. I haven't read much Buckminster Fuller which is really slack of me, but Fullerisms rub off on me from Dana, who has read and reread Fuller. (And Ackoff and Argyris and so on down the line.) But I picked Ruskin's Seven Lamps of Architecture of the shelf... I also put rereading Conrad's Heart of Darkness on the queue, just because it has been so long, and the time seems right (something dark to make me assert my light). And now that you're caught up on my reading. I need to get caught up on not tracing. ;-)

Hm... that reminds me about one of my formative encounters with serendipity. I loved Athol Fugard's plays and as a young adult in South Africa had the opportunity to see one where he spoke after or maybe before, but anyway he said he was asked if he intended all the meanings people read into his plays and he said he meant some but many were serendipitous. That struck me forcibly enough to stick with me all these years. It is about the emergence of art not just from the artist but from our encounter with their work -- how it is seen and shared so others see it too, becomes part of the art. It is part of the system of possibilities the work of art opens up to us. But our active encounter with the work, our sense/meaning-making is a crucial part of the work of art -- and the work of art. The real mental work (which may be highly playful and not at all work as dreaded duty but work as skip-happy mind tripping on eureka brain-treats) of appreciating, encountering, wresting from the work of art what makes us more and makes the work of art more.

As metaphors go, it seems to me that what we are looking for is ways to not leave threads (using an analogy to cloth not the concurrency sense) dangling in our code that are just asking to become entangled. Code is complex. We know from Dan Ariely about deciding whether to "send the patient to hip surgery or try tylenol or a stronger more specfic drug"... Code that is inherently complex enough and, compounded with accidental complexity, can leave opportunities open with as much consequence to cost and life experience hanging in the potential balance... When we leave complex option routes open, we leave decisions open to being made later, when there is less head in that part of the game, less context and deep grok level understanding of the "theory of operation" or the working knowledge of the behavior being designed and its supporting structures and algorithms. We want to be alert to where we can cut off the threads -- present no opportunity to create messy alternative paths that become dumping grounds for all possiblities that might arise. (Plant mint in a flower bed for an alternative great analogy ;) Yes, I'm afraid I cluelessly did that. Now it's a lesson that keeps coming back to taunt me.)

Serendipity is a mischief of emergence. But she serves Epiphany well!



For the Romantic in You Me

Looking for "failure of imagination" quote and found these

(I was looking for the quote where the angel places "the future in the palm of my hand" and those two came up. Sweet. :-)

Not doing it for you? Ok, how about this:

Dumb and Dumber



History, Repeating Itself

yep, shallows

Image: from The Pace of Modern Life, xkcd


Read your way to comfort with ambiguityCommunicating Vision

In 3 minutes, this gets a fair amount done in terms of expressing a technical direction simply.


Ambiguity and Requisite Flexibility

This pairs well with my blog post on Flexibility:

Image snip (right): from Explore, Maria Popova







Gratitude Friday

Grateful to Stuart Boardman and Jack Martin Leith for Twitter advocacy/connecting.

Trying to figure out why such enchanting -- complex insight in whimsical cloak -- work as Buttercup Festival gets so little advocacy...

Are we more apt to (re)tweet outrage than enchantment?

Are human murmurations but like those of starlings threatened by a predator?

Uh. Cute kittens excepted. ;-)

Extending awe and joy inspires and energizes -- ourselves, and those who lit within us the spark of awe. Return that gift, for it takes nothing away from you -- it takes a moment, but that moment is one of savoring and noticing the more closely what it is that lit awe and joy in you. That is a grace received in the giving!

Well. Nice to see that Christoph Niemann got Google doodle exposure for the first day of summer!



Closing Out June

I'm going to park a few notes here as I close out June.

This accounted for a few additional visitors to my site on June 25:


Phew. ;-) My brand of ruffyan silliness is safe here.

Astonishing how indifferent the world is though, isn't it? No sense of expectation. No openness to the possibility of wonder. Or even just curiosity...

There's the universe:

Indifference is popular!

And there's humanity. Sadly, humanity seems set on trumping the Universe?

Just kidding. But it is striking. Like a slap in the face. ;-)

Well, I thought Clint Nash showed a great sense of humor retweeting Grady's shoutout and my response. ;-)

I was totally astonished that Grady Booch mentioned my Trace.

And... Uh. Embarrassed! My Trace is... somewhat of an "acquired taste" sort of thing... And I deadpan playful... For example, not everyone knows that when I say my Trace is a brain upgrade I'm being heavily ironic, hence self-deprecating rather than the opposite.

Oh yes, more for the record:

recursion humor

What a world!

Smiles. Actually, what a glorious world! A great leader in our field was in London to receive the Lovelace Medal (which he was awarded last year, but the address and medal is given at the following year's ceremony), and he tweets about my Trace! How cool is that?

I hope you remembered to congratulate Grady Booch -- if not, it's not too late.

And in the category of Oh Frabjous Day! -- someone liked the Picture IT talk video! After 3 years, 1 like. Wahoo! There is kindness in the world!! Who knew? Well, well. Given that, I have work to do.


#ProudMom #NoNails

Riding across America

So proud of our riders, and a great action photo (from their photo journal) as the group of teenagers ride from border to border.

Proud of my lovely daughter too -- she told us that in a choreography piece she's in, one of the boys has to lift her above his shoulders and he is so tall she can wave to her friends back home from up there! ;-)

In both cases, being proud and thrilled for the kids, comes at a high price of nail biting (figuratively!) for the mom. Really, you should be proud of me, letting my kids do that! ;-)

Architecturally significant? No. And yes. Caring. Not being indifferent. Empathy. Imagination. All these things are at the heart of architecting. Because anyone who thinks it's just cold calculation, is in for a big wake up. We try to be rational and objective, but the funny thing is, we can really only be effective when our emotions are checked in and on the job. Without them, we can't prioritize (so can't make choices and decisions) where problems are wicked and complex, compounded with uncertainty and ambiguity... So I have just written myself a permission slip for putting my joy in my journal. ;-) Rationalizing*. An art form in my hand, is it not? No? I'm stung. Sigh.

And you didn't even miss me. Twice stung.

* That is a great big teasing wink at those who've read Taleb on antifragility. ;-)

[Ok, so I may caricature myself (too much?) but I expect that you are a sophisticated human fully being and sense my playfulness and don't take my self-(d)ef(f)acing satire at face value.]



I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog




June Posts

- Surfaces and Essences

- Some Laws to Keep in Mind

- Some Flaws to We Keep in Mind


Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker



- January
- February
- March
- Current


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


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



- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


More Archives




Chief Scientists

- Grady Booch

- Michael Feathers

- Martin Fowler

Enterprise Architects

- John Ayre

-Peter Bakker

- Stuart Boardman

- Todd Biske

- Adrian Campbell

- Louis Dietvorst

- Leo de Sousa

- Johan Den Haan

- Alan Hakimi

- Chris Eaton

- Roger Evernden

- Ondrej Galik

- John Gotze

- Tom Graves

- Nigel Green

- Melvin Greer

- Adrian Grigoriu

- Carl Haggerty

- Dion Hinchcliffe

- Paul Homan

- Brian Hopkins

- James Hooper

- Martin Howitt

- Kristian Hjort-Madsen

- Alan Inglis

- Jeff Kennedy

- Janne J. Korhonen

- Nick Malik

- Alex Matthews

- Brenda Michelson


- Sethuraj Nair

- Emeric Nectoux

- Doug Newdick

- Steve Nimmons

- Jim Parnitzke

- Ric Phillips

- Chris Potts

- Randall Satchell

- Praba Siva

- Serge Thorn

- Bas van Gils

- Jaco Vermeulen

- Richard Veryard

- Mike Walker

- Tim Westbrock

Architects and Architecture

- Charlie Alfred

- "Doc" Andersen

- Tad Anderson

- Jason Baragry

- Simon Brown

- Peter Cripps

- Rob Daigneau

- Udi Dahan

- Tony DaSilva

- Matt Deacon

- Peter Eeles

- George Fairbanks

- Kevin Francis

- Sam Gentile

- Simon Guest

- Philip Hartman

- Todd Hoff (highly recommended)

- Gregor Hohpe

- Gene Hughson

- Steve Jones

- Frank Kelly

- Kirk Knoernschild

- Philippe Kruchten

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Nick Malik

- Chirag Mehta

- JD Meier

- Kris Meukens

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Bob Rhubart

- Arnon Rotem-Gal-Oz

- Carlos Serrano-Morales

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Gavin Terrill

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rebecca Wirfs-Brock

- Rodney Willis

- Eion Woods

- Brian Zimmer

Architect Professional Organizations




Software Visualization

- Adrian Kuhn

- Jennifer Marsman

Domain-Driven Design

- Dan Hayward

Agile and Lean

- Scott Ambler

- Alistair Cockburn

- NOOP.nl

- hackerchickblog

- Johanna Rothman


Agile and Testing

- Elisabeth Hendrickson

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- CapGeminini's CTOblog

- John Daniels

- Brian Foote

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels

CEOs (Tech)


CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- Tim Brown (IDEO)

- BoingBoing

- Mary-Jo Foley's All About Microsoft

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites



- Marci Segal


Visual Thinking

- Amanda Lyons


Social Networking/Web 2.0+ Watch

- bokardo.com

- Mashable


Visual Thinking

- Dave Gray

- Dan Roam

- David Sibbet (The Grove)

- Scott McLoud


Leadership Skills

- Presentation Zen


Strategy, BI and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

- Malcom Ryder


Um... and these
- Nick Carr

- Tom Peters


Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network


- xkcd

- Buttercup Festival

- Dinosaur comics

- geek&poke

- phd comics

- a softer world

- Dilbert




I also write at:



- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010 

- Innovation and Agile Architecting: Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

- EA and Business Strategy: Enterprise Architecture as Strategic Differentiator, 2005

- The Role of the Architect:: What it Takes to be a Great Enterprise Architect, 2004


Ruth Malan has played a pioneering role in the software architecture field, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which emphasizes: architecting for agility, integrity and sustainability. Creating architectures that are good, right and successful, where good: technically sound; right: meets stakeholders goals and fits context and purpose; and successful: actually delivers strategic outcomes. Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like: the extraordinary moment principle; the minimalist architecture principle; and the connect the dots principle. Being agile. Creating options.

Feedback: I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I can be reached at

Restrictions on Use: If you wish to quote or paraphrase original work on this page, please properly acknowledge the source, with appropriate reference to this web page. Thank you.


- Links to tools and other resources



- Other Interests






Copyright 2013 by Ruth Malan
Page Created:May 30, 2013
Last Modified: October 24, 2019