A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

July 2013


What's a Trace?

For those who are new here, I used to characterize my Trace like this:

  • This is where I prototype/mock-up my thinking, so stopping by here is like... coming into my garage-shop and seeing what I'm working on in all it's stages of experimentation and incompletion...
  • This is the journal of my exploration, as I scout out interesting features of the architects architecting architecture landscape and territories beyond. I chart these features, but also try to make sense of them, reflecting on what they mean for our field.
  • This is a conversation, where I draw in other voices, add my perspective, and explore deeper based on the (asynchronous) interactions of minds.
  • This is my "platform for change," where I develop (and share) flexible variety / requisite flexibility necessary for designing and enacting complex systems
  • This is an open brain experiment. I'm giving you a preview of what it will be like when we advance beyond the social internet and internet of things to internet-of-directly-connected minds (no voices or hands needed to transport thoughts). Yep, overwhelming much... (talk about "big data")... Yep, messy. With ooey gooey human stuff mixed in with reason and rationality. ;-)
  • This is my personal maker space -- where what I am building through exploration, discovery and experimentation is myself, my point of view on architecture and being an architect.
  • This Trace weaves its audience into the narrative -- one where architects star in an unfolding story of our field. So... it must be awesome!

Now I characterize it like this:

Anti-fragile training

The antifragility quip is only original in permutation; it has precedent. [If nothing else, I take self-deprecating to new depths. ;-)]

More seriously...

Peter Bakker created an awesome storylines tubemap that makes connections among various of my traces. The view that is threaded here is time-sequenced, and the storylines map is threaded by conceptual relationships and building storylines.

The trouble with changing terrain, is that maps quickly get out of date. The trouble with something as big as 7+ years of tracing, is that it is a monumental task to map this Trace. Here is my partial attempt at mapping some of the space: Journal Map.

Both maps serve the purpose, though, of indicating how diverse and broad the space is, once we think of architects as leaders and influencers working with and through (in a good way) others to get big ambitious, complex, high value-creating, community and customer-serving things done. As innovators and (technical) strategists who identify and form new systems that add value and surmount challenges to provide new, differentiating opportunity to their businesses and communities. As system designers who design new mechanisms, and shape systems. And so forth. ;-)

Thanks for the tweet-out, and congratulations to Grady Booch on the Lovelace Medal!


Inspiration Point

As awesome people go -- the adults and the teens on this trip are way, way up there! Here's they are on the first day of riding -- at the Mexican border. 101 degrees F.

Mexican border

If you think something can't be done, think 15 years old and cycling across the USA from the Mexican border to the Canadian border. Then rethink possible!

Improbable for most of us. But not impossible. For most of us.

Ryan only found out about the trip and got a road bike about 5 weeks beforehand, completed the required training rides and then some, and got himself ready. That's amazing. The more so, for a nerdcave-dweller. :-)

The organizers have been taking teens on these three week-ish 1,500 odd mile rides for something like 20 years, since their kids were teenagers. They are amazing and this has to rank among the very top in leadership training/character-building for teens in the world! They keep the costs rock bottom, sleeping in churches and schools, doing most of their own cooking (when the local communities don't cook for them) and all their own clean-up, etc., etc.

Image source -- from the group's journal.

Pride aside, until he gets home, every day is endurance training for me (many states away)! They have ridden through hail storms, heat, and roads... with, like, cars and, you know, lorries... And serious mountains. You know. Downhills. And... Gulp. ;-)

If antifragility is the ability to thrive under duress and insult to the system, my antifragility capabilities are being challenged. And, as you can see from the creativity of this trace, I'm handling it.


(Fooled? By randomness?) ;-)

"Head-fake" come to mind?

Oh the things you learn here. ;-)

Like... working with Dana on the skills framework, he triggered off my using "organizational effectiveness" in the place of organizational politics, and we pair-stormed this alternative:

  • personal effectiveness
  • organizational effectiveness
  • strategic effectiveness
  • technical effectiveness

Organizational effectiveness is about getting things done, when they are too big to do oneself. While we place leadership, consulting, and organizational politics under organizational effectiveness, it surely overlaps with the personal (like empathy). None of these divisions are clean. For example, creativity may fall under personal effectiveness, but impacts strategic effectiveness and technical effectiveness. If we say that "making decisions (stick)" falls under leadership when the decisions impact (many) other people, the making decisions part may be strategic and technical, but the "stick" (as in enacted) is the organizational part, especially where much must be achieved through persuasion and influence rather than formal authority (and the other kind of stick, equating to punishment). [I must remember to get a ceremonial feather for the skills workshops. ;-)] Chris Argyris' work would lead thinking in personal and organizational effectiveness areas. Russ Ackoff's work has more to offer in the organizational and strategic effectiveness areas, as well as "technical effectiveness" if by "technical" we include social and socio-technical systems design. And so forth.


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 some seats available, and we would love to have you join us.

Keeping Trace of Things

Trace -- extended memory

Not only does my Trace serve as extended memory, but Google does a pretty good job of indexing it.... Though... Google seems to be getting worse at their core business right when we need better ways to navigate the information floods... Others find that too?

So, I wanted to hold onto this thought:

Nice to have a place to put this :-)

And this one:

keeping trace

There's "flow control" and there's "a place to put things" and they interact...

Sometimes tracing feels like tossing words into a void... And sometimes it feels like this. It is nice when someone waves back. And even better when someone engages.

I try to make the point that our work personas need to be humanized. Sadly, people treat my humanized professional projection like ... a bad idea... oh well. ;-)

He so totally gets the self-(d)e(f)acing satire dynamic, doesn't he?


Coupling and Cohesion

Understanding Coupling and Cohesion: with Kent Beck, Corey Haines, Jim Weirich and Nat Pryce hosted by J. B. Rainsberger

It seems to me that we could get more insight if we explicitly think about modularity and dependencies... These points (about modularity) were made (more or less***):

  • making changes: how scattered are the changes? High scatter makes it harder/more time consuming to think through and make the change and impacts likelihood of introducing bugs/missing something.
  • finding/locating/navigating/understanding the code (as code base becomes too large to hold in mind): useful abstractions help us chunk our mental model of the code base aiding location/navigation/understanding, tell ourselves intuitive/grokkable narratives about how the system and its key mechanisms work, helping us think through (inter)relationships, etc., etc.
  • (re)using chunks: less bulk to comprehend; less work to create and to maintain; make fixes or evolve in one place; leverage work/investment/expertise

And Nat kind of obliquely mentioned work assignments, but didn't address modularity as an organizational (work assignments, organizational ownership, resource and organizational scaling mechanism, etc.) consideration except by way of a glancing mention of Conway's Law*...

In addition to (considering) partitioning along change fault lines (putting things that are more likely to change together together) or to hide messy areas (where entanglement got out of hand due to neglect, or inherent complex interrelatedness or...) we may separate areas of high uncertainty or experimentation from more stable areas, or separate areas that need a certain kind of expertise, or separate at natural distribution boundaries, etc... We look to separation of concerns or responsibility cohesion in finding the natural structure of the system.

Ok then.

If we are going to have some form of modularity (decomposition), we're going to have (to have) connections (composition). That is, we introduce (explicit) dependencies (that may have implicit elements to them, like connascence of meaning).

But... (formal, explicit) connections between modules (using the term in the - general - modularity sense; that is, whatever our "chunks" are, given our development paradigm) are not the only kind of dependency.


Of course, these points were made, just... not in a cohesive way that would have lent more coherence**... Hm. Cohesive and coherent. Interesting relationship...

Well, I created a list of coupling and cohesion (and related) resources back in 2010. I'll have to update it, and add this video. ;-) More under coupling and cohesion here.

So. If I posit that there is a useful relationship between modularity and cohesion, and coupling and dependencies, what does that call to mind, when you want to refute that (tentative) observation?


* With respect to the organizational assignments/Conway's Law point: Sure, it gets complicated to talk about when teams may be assigned to stories or features that cut across components (in the general sense of "component of a system"), but nonetheless, to scale organizationally, entities (services, modules implementing related capabilities, whatever) are often assigned to organizational groups.

** It felt to me like there were too many people in the discussion, and not much diversity (of orientation)... It meant that the same effective storyline was being told in a very fragmented way across too many people, with the result that, for example, we heard a lot of deference to Kent Beck, but didn't hear very much from Kent Beck. And I was frankly hoping to hear more... And... The discussion on the visualization question was really telling...

*** That is not a criticism, only acknowledgment that I was paraphrasing and adding to the points that were made in conversational fashion, which is quite naturally a bit jittery. And that is not a criticism coming from stream-of-consciousness-trace me. ;-) There are upsides and downsides to most anything we do. Conversation zigs and zags between people, and gives it nuance and personality zest and surprising turns. But it is less orderly and topics may not run a satisfying course before they are taken in a new direction. (Which is also true of my Trace, which, afterall, is where the conversations in my head escape through my fingers.).

7/3/13: Ok. Today's tentative (be kind!) expression of the beef here:

Within a module (element, component, software entity), things are coupled various ways (or have co-dependencies -- temporal, shared data, depend on the same library and programmatic entities, the same attached meanings, etc.,...), and we know and accept this (we couldn't not have any of it; the question is how much). What we are concerned with, generally, when we talk about coupling in the contexts of modularity and "coupling and cohesion" is the coupling between modules. We want to minimize this, because it works counter to our reasons for modularity [e.g., restricting/limiting changes and their impacts and ripple/side-effects; ease of (re)use and picking up a piece and using it in a black-box kind of way (if there is a lot of, especially implicit coupling, we are more likely to have to get intimate with the internals to figure it out, etc.); etc.]...

Modularity works counter to other properties we're trying to achieve, like performance. But may support some properties, like scalability -- depending on our module boundaries... So there are tensions and forces/counter-forces that we are balancing, that make us want to put more stuff closer together, versus pull stuff apart....

Cohesion is about good criteria to modularize around, that will tend to reduce coupling between modules. Cohesion is about putting related concerns together (so separation of concerns relates to modularity -- in one dimension/there are other ways that separation of concerns shows up).

Tell me what I'm missing or messing up, so I can revise and refine and improve my thinking and/or expression of it. Please.:-)My coffee shop traces on technical debt

Oh. And while we're at it, I should mention:

While technical debt can mean lots of different things (within the same system), much of it boils down to breakdown of modularity or entanglements that have made their way out of close quarters and intimate relationships and start to act at a distance, on the one hand, and tight coupling to outmoded assumptions, on the other.

Hm. You'll see traces of this kind of thinking across the 7+ years of writing here (naturally; it is an architecture journal). Like this from just below that Gestalt Principles trace:

Interfaces! The strength and the weakness of systems! Parts, chunked according to the paradigm du jour (components, services,...), give us realms of intellectual and organizational control--units of innovation and experiment, units of expertise, units behind the walls of which we can simplify and refactor and otherwise manage (or not) "technical debt" or local integrity of the part. Ah, but parts needs-must collaborate to produce system outcomes, and therein lies the rub. Literally, for many physical systems. But no less truly for software systems

Shoot. So... I said that more succinctly and clearly in 2009! Sigh.

People really should have been, like all over how great my trace is back then, so... I could be writing novels now. ;-) Or something.

I wish I had someone I trusted not to treat me like an idiot to bounce my ideas about functional programming off of. Oh well. I guess I just have to push and pummel at them until... they just burst out of me...

And. Well, looking for a trace, my eye fell on The Useless entry, and I backed up to The Grace of Empathy and Poetry. Uhhh, maybe not everyone in the software field should read my Trace... but architects? ;-)

7/4/13: Some useful visual analogies:

and, uh, a biological analogy:

One of the most pernicious implicit couplings is to assumptions. Here's a neat visual analogy for what we learn when we explore changing our assumptions:

7/8/13: One of the areas that conversation left me wanting more coverage on was an exploration of dependencies and entanglement.

9/1/13: See also Learning to See


Two Kinds of Problems: Binary and Not

It seems to me that we have, broadly speaking, two (related, in practice) kinds of problems in designing software:

  • code organization problems like where to put things and what to name them so we can locate them, change them effectively, and such. That is, what are our abstractions and how do we connect them up to make bigger things? Driving concerns here include change/adaptation/evolution; understandability/grokkability/navigability/location (alternately put: making complexity cognitively and organizationally tractable); (re)use (in a product line/family, across a business, providing services to a broader ecosystem, etc.). [Code structure and code properties; "good"]
  • and we need to make things happen -- internal things and external things. Provide capabilities to the system, and to its users (which may be other systems). These are mechanisms and algorithms and we have a "theory of operations" or "how it works" focus to our thinking. [System capabilities and system properties; "right"]

As I caveated -- these are related. We needed to think across structure and behavior, holding one in dynamic, creative suspension as we think about the other, and back and forth between the two. How it works affects what we put where, and what names to give. What names we give impacts our thinking about how it works. For example, if we think of a biological (waggle dance of bees, fork), mechanical (bridge, pipes, filters) or social (broker, round-robin) analogy, that influences our design in terms of responsibilities (what it does) and assignments of responsibilities (where we put them) and names of the resulting abstractions, as well as how it works, hence interactions (impacting connections) as well as algorithms/mechanisms. Or the names of the abstractions suggest responsibilities, which we flesh out as we think more about how it works. There is an interplay -- how we design the structure to deliver the capabilities affects the properties of the system. And it is in thinking about how to make it work and achieve desired properties, that we are very much impacting the design of connections, but connections are structural (though not necessarily static). And so it goes. Thinking about our approach and alternatives and how to achieve desired properties across capabilities. Tradeoffs. Iterating on the design to achieve more "this and that" than "this or that." {Which may involve cutting some things out. I need to edit this trace! ;-)]

Uh. And yes... The nice thing about saying "there are two kinds of problems" is that the brain immediately starts looking for mud to fling at that notion! ;-) There is that classic "structure and behavior" aspect, but there is also the information flow and transformation aspect. Matters of state, and dependencies that are perhaps peculiar to software because we are flowing and transforming data ... and control (in terms of state)... and

I like to make things simple enough for me to understand. ;-) Getting to simple can mean wading through fuzzy changing thinking.

Oh well, if you read here, you know that I write to find where I'm being an idiot so I can revise myself.


[When I talk, I often don't complete sentences. Bad habit. Sometimes it is because my thoughts forked some time back, and the other thread captures my attention. Sometimes it is because I think the rest of the thought is too obvious to waste time (and bore fast thinkers) completing... Sometimes it is to suggest uncertainty... And sometimes it is to suggest there is more to be said, but it is time to move on. When I'm writing, the unfinished sentences are mostly of the last type. I think... ;-)

[I added the "good" and "right" in after a conversation with Dana. You know we go after "good, right, and successful" because the system must be technically/structurally sound (good) and meet stakeholder needs (right), but also must be successfully deployed and delivering outcomes -- "successful" is largely the personal and organizational effectiveness part I mentioned in a trace earlier this week.]

7/4/13: More, from bouncing ideas around with Dana:

  • good -- about the parts
  • right -- about the whole; (emergent) capabilities and properties of the system
  • successful -- about the whole in (various) context(s) (value network)

7/11/13: Dependency Principles, Ganesh, July 02, 2013



Not Crazy -- Uncommon!

From the cyclists daily journal:

"Tomorrow we continue to pedal deep into the heart of the Rocky Mountains as we begin the second half of this adventure of a lifetime. It's unlikely any student in America is doing something more challenging than this group of 60-some courageous people. These young people aren't crazy. They are uncommon!!!" -- Norm

We recognize that there many other teens doing great and challenging things this Summer -- unlikely and rare things, in the scope of middle and high schoolers' summers.

Sara and the kids at ballet camp have my admiration too -- they are working long days 6 days a week. And in "pas class," the 12 and 13 year olds are doing the fish dive. That takes real courage (if not for the kid, then for the MOTHER, who hears about this at a distance!) when the boy partner is learning too! :-) Fortunately Sara has a great partner... so I don't have to hold my breath for several weeks, right?

Being a parent is like being an architect. What you care so very much about, is out there taking its knocks and there is very little you can do to protect it from them. We hope

  • we provide helpful supportive context,
  • that the values and qualities that are built with some influence and perspective from us, but which are ultimately beyond our command*, have and lend integrity to what is accomplished, and
  • the outcomes are good.

* Often more influenced by us, the less we command and conscribe, and the more we gently shape through what we support and enable. Kids and innovators are, well, creative. And wilful. ;-)


Ideas. Magic. Steve.

I've asked participants in the upcoming architect skills class to read or watch something about Steve Jobs. Why? When I ask architects to name leaders they admire and seek to learn from, some... have trouble naming specific people. Maybe they feel awkward mentioning their father or mother or football or ballet instructor, or... Steve Jobs. No-one wants to be seen as a "fan-boy"... So, I'll just step up to that one and say you know, there is a lot to learn from the man. Like this:


Quote as image source: Steve Jobs quoted by 37Signals, Travis Jeffrey

Sure, a lot we have to learn from Steve Jobs is about how we are different, hold different values, have different leadership styles. But he was a remarkable man, who got remarkable things to happen.


Maslow 2.0!Maslow 2.0

"The notion is that you need to first be able to survive — which is based on having core skills and knowledge. Then you get to compete — which requires specific strengths and competencies. And if you’re lucky enough, you get to aspire to lift the entire field that you represent upwards."
-- John Maeda, Survive, Compete, Aspire

I like the notion that leadership is about aspiration driven by values; to sense that something needs to be better, to seize an opportunity to make a difference (add value, remove pain or frustration, etc.), and to rally others to participate in making that difference happen, despite all the challenges and inertial forces in the status quo, takes aspiration. Ambition. But the good kind that is about benefiting others, not just being self-serving.

Image source: John Maeda, Survive, Compete, Aspire

9/1/13: Abraham Maslow and the pyramid that beguiled business, William Kremer and Claudia Hammond



In Living Comes First, Brian Andreas beautifully builds to a climactic* recognition:

"You never create something from nothing. You create something from other somethings"

This is illustrated beautifully in:

"he sang my heart alive" -- Brian Andreas, Living Comes First

"people make the world come alive for each other" -- Brian Andreas, The Songlines of Chicago

Now I know why the latter has the title it has.

Some people in this world now, make me so happy that this is when I get to be alive in it! My family, you, and David Troupes and Brian Andreas number high among them!

PS. We need to put composition and choreography into their proper place alongside coupling and cohesion, don't you think? ;-)

* See Epiphany (in that not so Useless trace ;-)






Market Learning...

Hm. Insight or meh?

I thought that teasing out why the pressure is placed, is important and informative -- it shows us where to place attention as we help the field do better. Market learning cannot trump design learning, because market learning depends on (technical) design learning. If we snarl up the internal works, we can't move with the market (or what we learn about/from the market, which is a subset of the move-with-the-market problem, in that the market is itself evolving). So we may act like market learning trumps technical, but it doesn't last... (Generally speaking; heroics create exceptions. But we can't live in exception territory all the time. We burn people out. And tick users off...)

Um. Guys? Guys? Uh... guys?

Of course, how much we invest in technical design learning and structural integrity is a matter of judgment... so hard, especially if we devalue judgment/wisdom/thinking...

7/7/13: Perhaps it would help if I add: I see market learning as a double-sided matter. On the one hand, the business is learning about the market, how to better meet market needs (user needs, and better fit to the broader value network, tuning up production and supply chain, etc.), etc. And on the other hand, the market is learning how to use the product, how to make use of, get value from, fit the capabilities into their systems of systems.

So we have market learning, that has a facet that is about learning about how best to address the market, and a facet that is about time to value, quickly providing value the market gets excited about and hopefully somewhat coupled to. (Think of my dependency on Twitter, and yours? ;-), and you see a form this takes.) Doing so quickly, to increase market size, but also to seize more of the market, benefit from network effects and switching costs and so forth, to gain strategic advantage. Not just increasing market penetration, but delivering value that the market becomes dependent on, and coupled to. (When Facebook becomes your scrapbook, photo journal, timeline of things your kids do, and so forth, you -- and your friends and family -- become pretty effectively coupled to Facebook. If your music library is on iTunes, you may be able to move it, but do you even bother to figure out how (before that's made illegal)? Do you assess auto insurance carriers every time you replace a car, or just default to the one you already use? etc. Life is too complex to keep moving all our "stuff."). Pioneer and early follower advantages are significant (if played well).

But there is another side to Time To Value that can't conveniently be subsumed under market learning, and that is time to revenue which, for a startup running out of funds, or a project running low on sponsoring management or investor patience/risk tolerance, etc. can be a matter of survival. As far as pressure to rush and cut corners on design integrity* goes, there is also the matter of careers and may also be a matter of tech and management bravado... We don't do an especially good job of recognizing that whereever development is breaking new ground -- such as is often the case in competitive arenas, because we are seeking to differentiate, so doing something that isn't already being done -- we are doing at least some things that are untried and need to be experimented with, explored, designed and redesigned to do it better. At any rate, some of the pressure to rush may be real survival pressure like running out of funds or meeting a Holiday shopping window or getting a lead on potential competitors, etc., and some may be a veneer of bravado to cover uncertainty and move forward, instead of effectively managing expectations so that it is understood that we can have confidence based on experience and talent and still need to figure out how to make something work, and then figure out how to design it to meet the conjoint set of capabilities and properties that make it good+right+successful. I need to find a Steve Jobs reference about not rushing so much because the market is much slower than we think, or something to that effect.

Anyway, that is what I was getting at with my tweet, but there were sources of pressure to rush that I didn't include and I wanted to fill those in.

Actually, I have been meaning to pull together these thoughts about why the pressure (that gets us into tech debt messes) to create a blog post, and will try to make time for that in the next day or so. So, what are other sources of pressure to "rush" things, letting quality and qualities slide?


Good Citizenship: A Higher Quality

Today, Gene Hughson is my hero. :-)

Acts of kindness and inclusion make a community.

7/7/13: Oh, nice post:

Good and important points, skillfully made.

And. Thanks for quoting me and linking to my Negative Space trace. Hm, yes, while that trace is characteristically informal, it is a nice complement to Gene's post -- making points like "waterfall presupposes we can get it right" -- when the market (and broader ecosystem of supply, not just use, etc.) itself is learning with us what "right" means, often. Along with the point that adding features adds complexity and qualities slip. Um... yes... from the end of that trace::

Tonight Dana said to Sara "You need to keep some of your thoughts in your head!" I was the one who blushed.

Anyway, well done Gene! Except, of course, the best fractal and emergent adaptive design method is the Visual Architecting Process. ;-)


Taking Notes

I have been giving out Moleskine notebooks in workshops, and explicitly encouraging participants to take notes. So this, via mfeathers, is interesting:

Of course, tracing is also taking notes, and... Someone who reads here is going to tell Jurgen to read how I positioned this Trace at the top of this page. Awesome way to think about blogging, no? No? Sheesh! ;-)



oooo,  a keepr ;-)



Suspending (Dis)Belief

It occured to me that sometimes we have to suspend disbelief and sometimes we have to suspend belief. Our field has a tendency to creating demigods of gurus and golden calves of technology du jour. So suspend belief in that sense too. But what I'm really going after is in our process. We need to suspend disbelief and allow ideas to gestate, and then -- once they have enough of a start -- we need to challenge them, to strengthen them. Sort of like the immune system. Or something. [That analogy, as is the case with most, is only useful up to a point. We need to hybridize it with other ideas and analogies. Or something. ;-)]


Not the Right Image...

I... guess I just don't project the right image to be taken seriously in this field... But this field ought to be smart enough to discern who is smart and breaking useful ground and really helping. No? This field ought to be smart enough, but sadly... while Dana is booked 6 months out, no-one wants me. I said that to Dana and he said "I do, and I'm happy to pay a lot for that." He's so romantic. But garr, I'm as awesome as people expect me to be. You see, this is my approach. You know the common experience that you learn the most when you teach? Well, I come very well prepared, so anyone who is going to learn from teaching me, better be really well up on their game, right? Yeah. So very capable architects come teach each other and me, and learn more from doing so than if they just sat passively and drank from a firehose of some dominance-styled expert. Good deal huh? And I get paid for that? Well, it's hard to sell, but those who buy it, have a really good thing going because it is hard to get someone who knows as much as I do to teach. ;-)

And if you're susceptible to that rationale, hey, good deal -- there are some seats still open in the Architectural Leadership and Other Skills Workshop in Chicago/Schaumburg next week (July 16-18). We would love to have you join us -- we have so much to learn from you.

Watched Ugetsu tonight. It's about values and priorities, and explores fantasy, dreams, and ambitions, and when these go awry.

As images go... Guess what picture is on the cover of The Principles of Product Development Flow: Second Generation Lean Product Development? Come on, no cheating -- guess! So? Did you guess a waterfall? Noooo? Yes! Niagra Falls, I think! Donald Reinertsen has a sense of humor?! I'll have to read it! :-)



Oh. Thank You!

Hmpf. I know it seems like I spend my life on Twitter and see everything anyone ever tweets, but I only get "bucketfulls" of recent tweets when I feel like taking a "watercooler break" and rubbing virtual elbows for a bit of "get out of my thinking rut" Serendipity-as-a-service time. So. I miss a lot. And sadly I missed Daniel Stroe's tweet:

Some Laws

Thank you Daniel! Anyone who is not following Daniel, why not? He's been teaching me about architecture and life for closing in on 10 years (give or take a couple, I think... Was it 2005?)!

I saw it today when I looked to see if I was missing more of Daniel's "end of service" series. Seems like a great theme to run. But depressing. So it needs an optimism balance... :-)

It is my most cherished fantasy that one day someone (who hasn't read what I'm about to say) tweets "OMGoodness, OMGoodness! How did I not know about this?" and links to my Trace. ;-) [Of course, if you want to get into really deep fantasy territory, they add something like "the Anais Nin of software/systems/enterprise architecture", "art illuminating mastery" or some such indicator that they "get" what I do here. ;-) TMI? Aw shucks. And I thought we were like || close and up for that sort of intimacy. ;-) What's that? Ugetsu? Oh. Right.] So, this got pulled up into this morning's coffee break bucket (via a Grady Booch tweet), and another neat keeper came with it:



Elephants over the network... You have to love my Trace, don't you? Want another full-sized image? Or you could just go to the Decycles Facebook page. Be sure to like it.



Big Design Upfront versus Emergent Design

Some pertinent traces:

Earliest/last responsible moment and ground under the feet:

And for historical reference:

8/1/13: Oh, oh, this:


Code is... Documentation of...


Reminds me of this:


quoted in this post:

and tumbled from my fingers in this post:

You might also like:

Sure, we try to write code that "reveals intent" and conforms to the Principle of Least Surprise, etc. But there are (at least) three avenues that aren't generally self evident from code -- connecting dots (to drivers, desired outcomes, constraints, etc.); a "theory of operations" or how this works and why (we expect it to); and alternatives we thought about, but ruled out and why. All of these inform, illuminate, teach or mentor. They convey. They convince. They educate. They remove obstacles of disagreements and misunderstanding. They move design know-how and know-when and know-why from experienced to less experienced. And so forth. When people argue about (the usefulness of) comments and documentation. I want them to record themselves bringing another person up to speed on the system, or even part thereof, for complex systems. Then review that and think about it, and scale that up to 10 or 20 or 100 people. Think back to even that first person, and how much more they would understand, if the session was less about exactly this piece of code and what it does, and more about how it fits in its larger context and what purpose it serves and what constraints shaped it, and such, and what principles and heuristics caused it to be written that way. How much more useful could the session have been, in enculturing and bringing the new person up to speed on the design "big picture" and philosophy and principles and such? Would a high level "map" of the system help reveal and think-understand and think-reason about not just what-where-why, but relationships and properties? The code is the best medium to express exactly what it does in a very local sense -- but not why, not what the choices were. And the code doesn't naturally, and without significant intervention of mind and communication, convey bigger structures, let alone the "big picture" -- we either have to rely on idiosyncratic mental models or have some kind of visual and verbal descripitions for those design abstractions, how they work, and why they make sense and serve their purpose, providing capabilities that ultimately serve outcomes with more the properties users and the business care about.

One doesn't want to make documenting the system a life's work, but writing the The Way Things Work version might be just enough. Or, ok, the LMAX version. (LMAX provides an system-facing capability. For a business-facing capability, we might expect the dots to connect to the business capabilty being served.) It is not about what a person will understand about the code when they are intimate with it, but what is useful to understand to more quickly become aware of the shaping forces, the connection between capabilities and properties and how these are accomplished in the code, what to expect, how to be a good citizen within the codebase, and so forth. It is about mindset, not just about this algorithm or method, or that. And it is about being able to consider the impact of changes, redesign parts of the system, and so forth, more judiciously and effectively.

And the benefit isn't all down the road. Writing these things down, helps us get our own design thinking more clear -- we throw more questions at our own thinking when we are trying to make it (more) devils-advocate-proof. Within reason, of course. Judgment factors. No overdoing the writing! [Ahem. I do lead by example really I do. See. I set very good examples of what not to do. You hadn't thought of that, had you? ;-)]

And we try to make many of our assumptions explicit in tests -- with an emphasis on, for instance, pre (context) and post conditions (outcomes) and limiting conditions or boundary conditions. There are many kinds of assumptions that get coupled into code without them necessarily even becoming evident to us. They're just sort of like water to fish, not noticed. A publically accessable one that pops to mind for me is the early MySpace assumption that it was for dating, that really shaped the user profile data and search and other mechanisms they did provide -- and failed to provide -- to support social networking. Those assumptions prevented MySpace from becoming a more generalized digital gathering place, and meant, for example, that it didn't get the professional interest circles thing going, so LinkedIn had a pretty uncontested space to form and shape and MySpace missed a larger opportunity. One might counter that that is an assumption about the market, and hence requirements which impacted user interaction and screen design, and bubbled on down into the system, but these assumptions pervade the layers, and the inability to tack a new course is partly one of perception and partly a matter of how bred the assumptions are into the codebase and data design. But it does support the point that thinking about the design as design means we throw questions and challenges at the design assumptions before they are so baked in code that they have given us severe tunnel vision where the assumptions are cemented in the tunnel and we don't even see them.

Um. Does that make sense. What do I need to fix/improve/add/subtract?


Good points. And:

More here:


What's that Buzz?

Jiminy, how are these constraints? (Several of the examples -- like "write a blog post" and "make a video*" -- seem more like thinking workouts and design challenges, heuristics, idea fertilizer, rorschach-styled prompts to activate the subconscious, ... Useful, I imagine. Just more in the vein of a broader cast of challenges than constraints.)

Meme wrangling?! Oh wait.

As creativity under constraint goes, here's a neat example.

* perhaps there are instructions on the back, like "make a [3 minute video that expresses your design idea." Then the constraint is: use a given medium to do a specific task -- in a limited time (for extra credit on constraint forming). ;-) To be fair, I was using the constraint of providing a specific example to illustrate the power of an idea that just connects. Spiking creativity by inducing constraints connects. So well that even I am caveating my example. ;-)

7/30/13: Hey, bees refactor!


The Cost of Software Quality

And how buggy we are:


Living in Close Quarters: Privacy as a Moment in History

We're all in flap about losing privacy to official scrutiny, but the invasion is more pervasive, and we are more complicit, than that:

The globe is the new village ...except... it's not just the village gossip passing on the skinny, nor just coming-of-age teens peering through the knotholes...

Can't beat 'em, so join 'em:

There's a lot of good being done and to be done, but the underbelly is dark. Social platforms attract their share of hyenas and the like.


Rethinking Organizations: On What Basis...

Tangentially related:

Sense and Sensibility -- Revisited

A tad Nin?Looking for some of my writing that would further illuminate the upfront versus emergent debate, I reread my Sense and Sensibility trace. Two thoughts:

  • would this field hurry up and like my Trace already, so I can stop processing all this (boring) angst about its identity and worth? ;-)
  • it is good like! For instance? The notion that innovation and new ideas are conjugations is not new, but I do put it rather deliciously, don't I?

Ooooh... Who could recommend that and retain any professional dignity? ;-)

Cup half fullish :-)

Speaking of our children...

Decycling past Crazy Horse

Photo: Riding past Crazy Horse Memorial, SD..Credit: Norm Houze, from the Decycles photo journal

Ryan is in this one:

Ma boy

Photo credit: Norm Houze, from the Decycles photo journal

I am so impressed by these teens, college students acting as mentors and leaders, and the adults who make this possible. Norm and Cricket Houze are studies in leadership and execution excellence! Really an amazing couple, and they have formed a wonderful team around them.

If you haven't been to the Decycles Facebook page you should. It is encouraging to see technology being used to share such a heartwarming and inspiring story. (Ryan is on the Day 14 journal post photo, and in several photos from today. He cut his hair for this, so you know it was important to him. ;-)

Guess which is Ryan? Nah, couldn't be the playful one... ;-)

That's my boy!

Photo: Team Moose, from the Decycles photo journal (credit: Norm Houze)

I'll take some of the photos off to lessen the download burden just as soon as someone says something nice. ;-)




I'm going to put this Trace on hiatus. Summer is a good time to refactor and refresh -- and change habits and do different things that actually matter... ;-). Have a great Summer! :-)



1600 Miles!

The triumphant ride to the Bloomington city square, escorted in style by firetruck. They stopped traffic on Kirkwood for quite a while as cyclists were mobbed by families and boy/girlfriends. So proud of Ryan:

Homecoming -- Yay!




Notes I took when I was writing the Architect: When Leadership Matters blog post:



See also:


Entropy and Technical Debt

"Entropy is objective in the very important sense that when it rises to a maximum in any isolated system, that system is incapable of doing anything interesting, novel, or useful." Jeremy Campbell, GRAMMATICAL MAN: Information, Entropy,Language and Life


(Bit shameless putting that scrawl up for potential view...?)




Delight ...and (Dis)Order

I "did" delight as a theme for years leading up to an emphasis in Fractal and Emergent. Then I guess I sort of dropped it from explicit conversation, though it is very much part of my ethos. So I was delighted to be reminded to put delight back in the spotlight of our attention with I'll Be You And You Be Me (reproduced in her blog by Maria Popova). The "a dream for you" sequence is! Delightful! :-)

In one of Sara's songs, there is a line "Life is a constant strive for perfection." That is the kind of purity of truth that the tuning fork of a (very special) 12 year old can sound for us, that a Buckminster Fuller reaches wrestling more deeply than the rest of us.

Architecturally significant?

“disorder is easier and more permanent than order, which is difficult and temporary" -- Jeremy Campbell, GRAMMATICAL MAN: Information, Entropy,Language and Life

Consider how much order there is, not just in the built world but in nature. How much beauty. How much there is that just cracks us open in stunned amazement, in awe. And with it, that rush of delight:

Where awe cracks open, joy spills out.

When we look at the verdant richness of a jungle, we don't see the "order" of croplands, and yet the order that emerges in the jungle enables interwoven cycles of Life so rich and complex it is beyond our comprehension unless we tackle that comprehesion along various interwoven dimensions, some synthetic (in the Ackoff sense of synthesis), some analytic, all incomplete.

Of course, the order of the croplands has its beauty too. I was awe-struck, cycling yesterday, by the mix of geometric and wild that produced a different kind of rural beauty than that of the forests.

Again. Architecturally significant?

Entropy and order. The strive for perfection. To delight. Or even just to create "habitable" software for users and developers. And more. Complex and interwoven notions.

Another line of Sara's song is "Love is a constant fear of rejection." Love crucially opens us to new avenues of becoming in the individual and conjoint sense. In that state of openness to the connection of love, we are at our most utterly vulnerable. Love dissolves boundaries and, with it, isolation. It is a salve to existential angst, coupling us into something bigger than an insular self. But the openness and the connection are tender-vulnerable. Fragile. And not to be taken for granted (at least, not in a way that rends the connection).

In delight, we experience a rush of our humanity. In love, isolating insularity is breached. I think it is foolish to think that feelings are not appropriate for the workplace*, just as I think it is foolish to think that "order" is (necessarily) regimented. Alternately put, there can be a lot of order in what might appear, to an eye that doesn't know how to look, messy. Or it can just be messy and entropic in that Campbell sense (quoted above). Where it curtails and inhibits in ways that are not useful or adaptive.

Interconnectedness is vulnerable.

I like the structure of the song -- Sara's juxtapositions take us by surprise, and make us (re)think the balances that are delicately constructed around the pivotal pattern in "is a constant." Creating order, striving for perfection, creating interconnectedness, is an ongoing dynamic process that holds much in creative, dynamic tension. Love connects, but contains also the fragility of that connection and hence also the vulnerability of rejection.

We connect the world, and rend the world more vulnerable. In systems development, our striving for perfection is a striving for harmony, a fit to purpose, to context and a fit among the parts, to acheive that harmony within larger systems, ecosystems, and hopefully Nature.

Obviously I'm going to have to strive to make this piece make more sense. ;-) But I think it goes after the heart of the matter. In many dimensions. :-)

(Chatting over coffee with Dana Bredemeyer early this morning raised several of these themes, and Dana mentioned Fuller's insight -- "life is anti-entropic." Dana also relayed Erich Jantsch, in a talk Dana attended, accentedly quoting "there is order in random-i-ness." Also interesting/relevant: Order Out of Chaos.)


* Of course, the love that connects is of different kinds -- this is a sweet reminder I Think I Am In Friend Love With You (via Maria Popova).

Well, back to refactoring and fighting entropy. The version if takes today is close to home... Reclaiming the space under the stairs from the detritus of decisions neglectfully avoided, creating a wash of creative destruction that spreads disorder and requires energy to rework into a new, fragile moment of order. :-)


Catching a Thought As It Flits By

Some take the stance that art is an exquisitely peaked abstraction, that expresses an essence of meaning through an invitation to see, to comprehend in some deeper more significant way, but I think that art can also be truth (at least a sense of it) addressed so head on as to appear, once put before us, so simple that we don't notice we were missing its significance before.



Breaking Normal

Have an awesome rest of summer (or winter, as the case may be). :-)

PS. I'm not rage quitting. I'm sad quitting. There's a difference. ;-) [Don't worry. I have meaningful awesome work to turn my extra cycles to (and, being code, it is way more responsive to me than people! ;-). Besides, it's not an absolute or sudden leaving, since client work continues until the other work is financially self-sustaining.]

Putting away architecture notebooks... I realize I've done some good work in this field, and a lot of it in this Trace!! ;-)

[Thanks Peter. You're the best, most warm and responsive friend. You make it feel good to be alive! :-)]

7/24: Somebody twitter dm'd "what, again?" -- someone I've never heard from; I think it was spam. ;-) But yes, again. If you've read along here a while, you know my "Pandora saw hope, but I suspect it was just the flip side of denial." That's a playful wink. We really have a lot, lot, lot to do, to build a much, much, much more useful set of tools and eventually platform. So, expect great things. And if I slide back into tracing (like in this moment), don't worry, it won't last because 7+ years is a long time to keep doing the same thing and keep hoping that a few more kind people like Peter, Daniel, Stuart and Gene will show up and be nice. ;-) [But great galloping jabberwockies, the SRP/OCP tweet-scussion makes me wish I was still chattering here. Conclusion -- if you see me on Twitter, revoke my account privileges. Breaking habits means restructuring the things around the habit. Easier said. ;-)]

7/27: Should I be pleased or embarrassed if people ignore my "I quit" tantrum? ;-)




Oodles of Doodles

As I banish my sketch-notebooks, I can't resist sometimes peeking inside. :-) And (over-)sharing the ruf-ness. (Oops.)


Just different prisons... So different prisoner's dilemmas...? Collaboration and compromise. Seems like the C's, including communicating, are hard to do...

Innovation happens when new connections are made. Unlikely cohorts, in most organizations:

New connections


Ye-es... I'm trying to clear my office and my head enough of one set of habits to make new grooves around another more useful set of habits. :-)

Other 3 C's and circles here:



Habits and Happiness

“Man is the artificer of his own happiness.” ― Henry David Thoreau, The Journal of Henry D. Thoreau

Just as soon as I manage to break this Trace habit, I'll permit myself to trace again. ;-) I write with the expectation that there are people in the world who would get that what I do here is not more same-old same-old. You. And perhaps a few others. Incredibly smart people with generous-kind hearts to match their amazing minds. That may seem like gratuitous ego stoking but even if, worst case, that is all it is, what of it? Would one person standing out from the mass of humanity and just noticing those who are different enough from the homogenized pack to read here and saying "wow, I write at a minimum in a way that takes smarts to simply parse, and kindness to attempt to do so" be so bad? I jest. I expect readers who are sophisticated enough to know that playful layered ironic self-deprecation isn't the groveling obsequiousness of a low status animal. Rather, it takes a certain kind of confidence in one's intellectual authority to eschew (the usual) status-marking. ;-) One who recognizes we can't -- shouldn't want to -- escape the animal that contains us. But we can create an interrelated parallel social world that is more networked than hierarchical. More mutualistic than competitive. More filled with awe -- and more demanding of ourselves.

But now. I have the work of my job and the work of building a new paradigm. In code. Woohoo.

"Happiness is unrepentant pleasure." -- Socrates


And Since No-one Else Will

This Trace is filled with such awesomeness as this:

9/18/09 Inherit the Wind

Tonight we went to a performance of Inherit the Wind by our local theatre company. It is an awesomely good play--a good, right play for these times we live in! A reminder of the fragility of man and the traps our ego lays for us, and the greatness. The greatness of those who defend what it is to be (the best of being) human. In essence, it is about "defending the right to be wrong." Defending the right to ideas. The right to question.

If one is going to take intellectual risks--like, say, writing this journal--one feels pretty strongly about the right to be wrong! Hypothetically speaking, of course. Grin.

Ryan was especially taken with:

DRUMMOND. (Honestly.) I’m sorry if I offend you. But I don’t swear just for the hell of it. You see, I figure that language is a poor enough means of communication as it is. So we ought to use all the words we’ve got. Besides, there are damned few words that everybody understands. — From Inherit the Wind, by Jerome Lawrence and Robert E. Lee.

Of course, Drummond was the lawyer in the landmark case, so he wasn't in the pictures (sketches/diagrams/models) business. 

We inherit the wind. And [the] UML. And we're at a great point in our field, where we're learning the "and" lesson. Models and Agile make a handsome couple. And they may give birth to some weak ideas, but we retain (or must defend) the right to fail and learn. And that's the big idea isn't it? Making failure fast and cheap, so that success is more resounding. Weeding out the weak ideas that don't fit the context or purpose so well. Being free and able to hold Darwinian ideas, to apply and adapt them to business and product ecosystems.    

I'll take unrepentant pleasure in my writing. Someone has to. It may as well be me. ;-)


Ok. Who Killed Pictures?


I suppose we can't get away from the tribalism. It takes so much ballyhoo to get anything accepted that it's kind of like rallying for battle or something that runs deep like that. With the result that we rend deep schisms and swing the pendulum between extreme positions.

UML is a visual language. The utility of the conventions it offers is in creating common understanding -- including between people and machines. But the utility won't increase if we don't treat it as a living evolving thing. And if we don't treat it as a medium for expression that we get to be creative with. When our thinking is loosey-goosey because we're feeling our way, exploring formative ideas, hashing out conceptualizations of what the system could be and how we could possibly conceive of building it, exploring ideas for the design and evolution of its capabilities and mechanisms, we can -- I argue should! -- play it fast and sketchy. Being pedantic about notation when the thought process needs to be fleet is putting attention in the wrong place. But there is also a time for being precise in what we communicate, and reinventing the means to be precise by defining a visual language every time we use it would be plain daft.

So I don't think the issue is with UML. But the leadership of this field generally didn't help, treating architecture and design with derision, or at least holding it at arms distance like a stinky diaper. Might one argue that taking design out of our conversations cost the broader field a decade? A decade in which we shunted visual design off the slate of concerns in curricula as well as on the job. Could we have done better? And what can we learn, to better serve us moving forward?

See also:

Of course, being the visual design person of note (yes! wink), I have written a lot, lot, lot about it. Here's a sampling:



Rationalizing Irrationally

It is great that Kathy Sierra is back. One day, this field may realize that I was here all the time, but it steadfastly refused to be curious -- because it scuttled architecture and visual off the lemming cliff? (Yes, humans invented the proverbial lemming behavior; lemmings themselves aren't so potty.) Or ...because I show up too much?

Well, since it is the end of July, I put the July traces back so I can turn the page, so to speak. A few people were nice about my Trace, generally more by implication than directly. I still have to regroove my habits. Evidently it can't be done... sigh! But Dana spoke for the field and said all the direct nice things I deserved to have someone actually say. ;-) So hopefully now I can stop feeling trashed with all that the silence implies, and shift my attention. :-) Oh, believe me, I'd far, far rather be trashed by silence than trashed and harrassed the way Kathy Sierra was. Popularity was never something I wanted; it is too dangerous to tender spirits. A little delight at what I do is nice, and I have been sincerely grateful on the occasions that a particularly generous person like Peter has been bold* enough to express enthusiasm for my work.

* I write audaciously. I know that raises the barrier for anyone to actually recommend my Trace. But I believe things. Like I believe that we have to shift from the factory era compartmentalization of business personas and recognize we need to bring our whole personhood to work, to embrace and contend with this fallible-glorious human creature we are, pulsing with hormonal foible, with awesome attentional properties and deficits, the struggles to be civilized human beings capable individually and collectively of marvels and atrocities... The 7 year old Sara's poem comes again to mind:

Compasses are for
Learning how to
Use them

We wouldn't be human beings if it wasn't an active process of becoming. This moment of being is important -- I am. But I feel my am-ness in good part through what I care about, which is how I move from my past into my future, shaping myself with choices and being shaped by responses -- mine, and yours.

I think

"I feel like a locus of identity" -- mfeathers

is incredibly profound -- a moment of convergence of lineages of philosopy (including the philosophy of technology) compressed into something so multifacetedly crystalline I'd have to declare it a poem. (Perhaps epigram would suffice. Anyway, it is an exquisite composite of abstraction, pregnant with meaning. It lacks other lines, but it has distinct lineages. Its meter sheds and bears attention marvelously. That is a mischievous wink, lest you forgot the title to this trace!) But I won't trouble you with my explication. Still, no-one bothered to retweet it. Did no-one see what I did? This field could stand to have someone like me.

It is hard to read Nassim Taleb, because he puts his "grumpy old man" (I'm quoting) self into his work. And it is hard to read my Trace, because I put my quirky .. er... whiny little-responded-to self into my Trace? With Taleb, many of us feel we need to read past his presentation, or despite it, to get to the good ideas that chose him for their conveyance. Chose? Yes,

"I experience the writing as given to me — sometimes, almost, as dictated. I let it come, try not to interfere with it. I respect it, because it’s me and yet more than me. It’s personal and transpersonal, both." -- Susan Sontag

(IF you didn't get the wink in chose, Elizabeth Gilbert's Genie might help.)

I suppose if I am to show up in my Trace, I should filter out the identity crisis stuff. I don't, because I sort of feel my identity is part my responsibility and part yours. You read here, so show up. Be delighted. It's good for you to be joyful and grateful. Seriously. Best antidote to hubris is gratitude and delight in others. And reflecting some positive back to me is a great antidote to the enormous existential angst that is produced when one looks for one's reflection and finds none, for weeks and weeks, even months, at time! It makes a person feel invisible. Silenced by oppressive silence. And suchness. [Nice try? The title, dear Watson, the title.]

A selection of thought crumbs dropped, from time to time, by my nascent alter-ego:

Ah, the abundant wilderness, its indifference to us striking in the opposite reaction it wells in us!

Nature's ultimate indifference, foreshadowed in all the indifferences and impermeabilities of others to us, inspires a defiant radiant being.

Our dreams give us that welling of rebellion, the passion to resist the damning damping dust of indifference


Played with invisibility as a theme today, but it got spooky.

Yes, like "I feel like a locus of identity," those lines probe the big question. Through relationships, we explore meaning. Emergence is a thing with us. ;-)

Image: By Sara B., from a year or two ago. In my sketchnotebook, so I own it, right?


7/28/13: We all contribute to others' identity, for it is socially constructed. Oh sure, we need to take upon ourselves the real creative (combinatorial and inventive) work -- and discipline -- of the definition of our self, if we are to create a self that is truly distinguished. But even so, we are empirical creatures too, and the reflections others provide us factor in our self-image because we test our internal reality against the feedback we get from the world. For those of us who swim against the currents of conformity, it is important to be bolstered, now and then, by those who see something unique and meaningful and important in what we do.

8/4/13: Anyway, while each person is very much responsible for their own self, for developing a self they esteem, we, in their context, play an enormous shaping role too. To see that, take it further: if we belittle a person, take them down, that is a part of reality they have to contend with. Sure, they might be able to build that into themselves as a strength, but how foolish the position that they ought to be able to. If a person is chronically hungry, do we fault them? How blind and small minded a position that would be, no? So we acknowledge that the negative shapes. The negative space of silence is, in so many ways, good. Necessary even! But not consistent, determined, silence on what a person does. Not a determined refusal or even just a lethargy when it comes to responding to them.

7/22/13: Imagine if people in this field were warm, interested in advancing our understanding and practice of architecture, and advocated (conveying with enthusiasm) the good and important work others do. Imagine! Ok. That's enough fantasy. Let's get back to work.


Serendipity's Mysterious Weaving

Last night, looking for a Hafiz poem to read to me, Dana stumbled on and read this quote to me:

"If I tell her she will not believe me. You may remember the old Persian saying, 'There is danger for him who taketh the tiger cub, and danger also for whoso snatches a delusion from a woman.' There is as much sense in Hafiz as in Horace, and as much knowledge of the world." -- Sir Arthur Conan Doyle

Unremarkable? Do you know what it is from? A Case of Identity. There it is again. Identity! An interesting story, leaving an open question very relevant to our times.

Seeing a play on "The future is already here — it’s just not very evenly distributed" (WIlliam Gibson), I was reminded of Voltaire and Leibniz. And this musing on brain play and synchronicities.

"The future is already here — it’s just not very evenly distributed" is delicious in a way that I delight in. The "present is pregnant with the future" delights me too, for the imagery is full of expectancy. ;-) Ok. It is full of allusion to the conjoint, and the intercourse of ideas (what social lives they have!). And such sedious sensuality. Apparently NSFW, if we consider the way we control and gate the information flows in organizations. ;-)

"The present is pregnant with the future" (Voltaire) -- <le gasp> what social lives ideas have!

There they go, conjugating again. Voltaire. And that Ruffyan me. ;-)

Ok. Who else would write that? Huh? Huh? And it so needed to be done. No, no, really. It did. We shouldn't confuse derisive, abusive, oppressive sexual overtones that disempower and signal dominance, even aggression, with enjoyment of sensuality or context-fitting horseplay.


7/31/13: And demonstrating how much the past was pregnant with today:

Existential Angst. Take n.

Since I already backed out July, it's only the most curious and wise reading here. Intimate, no? I'll tell you a story.

When Sara was a very shy 3 year old just starting preschool, she didn't have any friends. She created a game she called "Curious Kitten" which was a game for only one player. The player would explore about and find magical enchanting things. As she played the game, other kids would see her having fun and ask if they could play too. But she'd have to tell them no. It was a one player game, you see. 

So there were those who recognized Sara's special qualities, and wanted her to play their games with them.


"So I want to write my words on the face of today" -- Blind Melon, Change

We can build with what life gives us, or break. Better to build!

I like my "baggage" -- it bursts with wonder and color and tenderness, but it's also full of grist for understanding and imagination!

PS. If you're going to read a journal, you might expect to get some existential angst. The human condition has its share of pounding fists on the various walls of indifference we find ourselves trapped in. Whether we despair because a project we care about is cancelled, or because the lack of positive response communicates a spirit pounding "meh," or we can't persuade others to help build out an idea we have to change the world, someone we care about rejects us, and so on, we suffer indifference at some points in our life.

“I write only because
There is a voice within me
That will not be still.”
-- Sylvia Plath, Letters Home: Correspondence, 1950 – 1963

8/2/13: Reading ee cummings last night, this popped out at me:

"there's nothing as something as one" -- ee cummings

And this particular one is, among other things, exploring the individual fracture at the confluences of social.

A journal is a particular form, which, if it leans into art in any degree, may be that part of art where the "I" is explicitly entered into and explored. Much of art eschews the lense of I, but in this time of fracture and existential angst (we're wrecking everything; we're not so smart; corruptibilty and greed have put holes in the ideal of capitalism; compute is outstripping us in ever more arenas; etc.; etc.), technology has to reach for art and philosophy and the question of "I" becomes crucial to investigate.


I write with a carefree abandon because the veil of words means only a very special and small audience reads here. It is the big joke of our times. Needles in needlestacks. A surfeit of exception.

my imp is mischief. it juxtaposes firefly flashes with the ego's beggar's cup, highlighting the responsibility-shed of the digital shallows

I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog




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:July 1, 2013
Last Modified: October 24, 2019