A Trace in the Sand
by Ruth Malan
Happy New Year!
I hope you have an awesome 2014, filled with dreams and realizations, joy and becoming.
What's a Trace?
My Trace is a playground for developing ideas, for exploring architecture and the role of architects. I don't know where these ideas are going to come from, so I explore, finding the dots to connect and sharing them, and the connections I make, playfully and thoughtfully, here.
On February 3, this Trace will be 8 years old. EIGHT YEARS!!! Eight years of inspired and inspiring exploration, investigation, probing, discovering, leading, helping this field to know itself and reconceive itself. No? oh....
Well, anyway, until January entries mass, perhaps you might like to take a look at traces from last year? January perhaps? Or February, if nothing else then for the Trace Turns Seven dragon! Or use the links in the sidebar on the right and let Serendipity drive. Or use the wonderful storylines tubemap by Peter Bakker to find traces by topic.
Passion, Energy and Flow
Dana observed, watching Man on Wire, that when intense passion and energy is poured into something, the very universe seems to organize around it! The impossible happens.
It is a wonderful image to start the year with!
Software Architecture Workshop
I'm teaching an open enrollment Software Architecture Workshop in Boulder/Louisville, CO on March 24-27, 2014. You should be there! ... Unless you're in Europe, in which case you might want to snap up one of the last few seats in the Software Architecture Workshop Dana Bredemeyer is teaching in Eindhoven, The Netherlands on January 20-23, 2014
Got around to seeing Joss Whedon's Much Ado About Nothing. Hey, we only got a 10-ish mile ride in today -- sure temps were above freezing... but not by much... which made for icy fingers. So we took the rest of the workout indoors. Last night we went to see The Secret Life of Walter Mitty... Just think, those two amazing movies bookended 2013-2014! And we went to see the New Year in looking at the stars from a dark spot in the country away from light pollution -- and were treated by the Universe to meteor just a couple of minutes before midnight. And last night and again tonight we were thrilled by Sara who played the piano and sang the latest song she is writing (it is a heart-breaking breath-halting thought-arresting lovely song -- the music, the way she uses her voice, the timbre and expression in it, the giddy loveliness of it) over and over (I had to pay in marmite on toast and, for my greedy requests for repetition, dollars, but hey, it was worth it -- to be held suspended in a moment so utterly lovely, well, is worth a price...)...
Many Beauty. Such Wow!!!
How about that for a view? And decorated for the season. :-)
Dana woke me up this morning saying "It's an emergency" but he didn't sound distressed... It was a beauty emergency that couldn't even wait for coffee! Now that's an emergency!!!
What is not profound about exuberant sharing of beauty, huh? huh? ;-)
Several people have supported my Trace on twitter with retweets and directed replies to tweets, but in making the 140 char cutline for a #ff tweet, I narrowed it to those who initiated a tweet shout-out for my Trace in 2013.
I am very grateful to everyone who has extended collegiality to me in various forums and forms.
As this Trace hurtles towards its 8th birthday, questions of identity and merit tug at me -- again. Silence on a body of work batters and thwarts egos. Consider that so talented a man as Rodriguez was silenced by silence. I hope you'll grant a little salve to my battered ego, permitting me to reiterate a positive framing for what I do here:
If you want to discover if the claim is overstated, may I suggest reading the traces from October 2012? I experimented there with an overview at the top of the month's traces, and a “grok check” at the end of each trace. I only tried that for a month; no-one said it was useful, and I was worried that it risked insulting anyone reading there, and I was concerned that making the shaping insight stand out in relief, jeopardized other insights that would emerge at the interaction between the trace and the mind of its reader.
What makes something profound? It sheds light on the human condition, and its struggles? Ahh, what mortality thrives in us... and crushingly embattles us. It is such a signal quality of our being, that we strive to do something meaningful, and yet no matter how much we strive and accomplish, our work only achieves that status if others allow it to be so. Hence, the work of seeing, appreciating and connecting, of weaving and including, is important work. You do it, your way. I do it, but I try to make it personal, richly hued with seeing, appreciating and celebrating the people of our field, as I weave their ideas into a richer fabric of understanding of our field.
And this Trace is, too, part of a profound quest – to advance our field by helping to shape how it conceives itself, as well as giving it tangible tools to do its work (the aspects that are people-oriented, such as leadership and being collaborative and co-creative, etc., as well as the core matter of design, the problem designing-surfacing and solving, etc.). And part of my quest is to make bringing our whole quaking, quivering, yearning, striving, tender selves to our work, for it needs to be creative and vibrant and… well, human. If our work is to have that "quality without a name" it has to have design integrity and be shaped with a keenly developed aesthetic, a uniqueness and distinction that comes from being a full person, with experience to bring to bear on solving real problems, but a sense of structural and design integrity and beauty. As we compete with, and are extended by, computing, we need to thrill at, enhance and cherish what makes us human. And so forth… there is a dynamically evolving personal philosophy that underlies what I do… and lends an integrity across all the seeming chance snips and snippets that might strike one if one merely glanced across traces.
If we turn our attention to traces, they go after deep and hard topics in our field (broadly speaking, covering software and systems architecture but also enterprise architecture), explore them with intellectual curiosity, openness, and inclusion of the thoughtful insights of great minds, and develop new insights that expose problems in our field, help shape its identity, its self-concept, its principles and practices, and so forth. That they do so dancingly and playfully is merely style – a style that I hope helps us enter into tough contemplations without being defensive and resistant…
But. It is hard not to get dispirited when positive reflection is rare. If we value a body of work, we need to say so, or the silence will crush it.
1/10/14: Looking for "why architect" traces, I reread this:
It occurs to me -- if you are new to my Trace, you might want to go back a year or three and read there, for many topics, like visual design, got covered more extensively then. Taking a step back and reading entries from a few years ago may give you a better introduction to what I'm about.
Okay, this isn't going to seem like an excusable humble-brag at all at all, but it is so creative and wonderful I have to share Peter's tweet (right):
That is one of those images that inspires, like a vision or ... <trumpet sound>... a beacon. ;-) Seriously, it captures what this Trace is muchly about -- connecting ideas (and via them, their people :-).
(The link is to Peter's amazing storylines tubemap of traces.)
1/6/14: And that is what collective intelligence is muchly about -- creative mashups and insightful connections that grow our understanding, or just are fun!.
This, via Dana Bredemeyer:
Interesting seed to contemplations on enterprise architecture?
Image right: Zombies Are Nuts About Brains, Terry Border
This article, written rather dramatically perhaps, prompted a little shower of conversations in my field of view and interaction:
I playfully pointed to the slippery slope BF, because... well, we do so relish those slippery slopes to downfall, don't we? She says, climbing out of her SUV. [Before you judge me, may I recommend a few Terrence Malick movies??] ;-)
How do I get from closing of minds to matters of collective conscience, ethics, ...individual morality...?? Well, discourse. How are we to get to a better understanding of the complex perplexities that befall us, unless we can have open debate? And sure, some of that debate is going to be stated in "performance art" terms of colorful hyperbole. Even the pieces that draw attention to the hyperbole of exclusive occluding views on the extreme self-righteous reaches of atheism and religions, of science as dogma and territorialism (oh, I can do hyperbolic rhetoric with the best of them, ...and do?) and such, can be shimmeringly extreme in their provocations. ;-) Partly, in this attention glut, perhaps we have trained writers to go to the kind of excess of glitzy entertainment, to play the dominance angle with pompously large, colorful overblown statements, to garner attention? How am I doing? Do I have your attention?
I think Terrence Malick's movies are important (though not to everyone's tastes, not just for content but their dense/richly nuanced and textured and layered and referential and yadda film-as-art style), for they take us into difficult material. They don't make moral judgments, but the very subjects are deep into territory most of us do not venture into, at least not IRL. They probe at the interaction between individual and collective, or social morality. Big questions of how we humans hurt each other, individually, and in something as big and impersonal, yet deeply, devastatingly personal, as war. But also how we love, and tend and open ourselves to others.
It is one thing to tsk tsk at Google turning its back on "do no evil" and another to figure out what the jabberwock we mean by evil in a world where massive surveillance is "clearly" evil but ads that take info from our shopping cart on one site and stalk us as we move from site to site, flashing their goods at us, are "fair" game? Or reach their grubby digital hands into our emails, and use what they learn there to push solicitations at us? We twitter-flock in outrage at personal infractions like dongle-gate, where the heated flaming and shaming reached such a quick pitch that people were hastily, decisively fired... Awareness was raised, crucial conversations were had, but at great personal cost to those involved, and broader costs of creating fears about speaking up as well as fears around what can and can't be said between individuals where they can be overheard... While I wouldn't encourage jokes that debase people (whether they can hear or not), inflammatory hyperbole or the flocking flaming, I do think we need to be able to have these debates and conversations and become more aware -- hopefully reduce the cost and penalties involved, but also not shut down the mechanisms that allow voices that are otherwise dinned out, or too intimidated, to be heard. We have a whole set of "interesting," often -- sadly -- hurtful, dynamics in play... But, whether it is climate change and flagrant conspicuous consumption of fossil fuels, or the plight of women, or the plight of boys, or the invasive spying on our personal and professional communications and lives, or the use of our habits and explorations to sell to us, or ...robots taking jobs without any social net to catch ever more (economically, socially and politically) disenfranchised people, or... putting our investment into making computing smarter without matching investments in helping humanity fully deploy its smarts... you get it? Long list. We need to be able to express these very different views, and be able to share the different experiences, because humanity is not all the same-same-same. But we need to traverse and explore these moral quagmires delicately and not go all moralistic ballistic... or worse... And that gets me back to Malick. I really like the way he leaves it to the individual to explore tough territory and draw their own conclusions. If we try to dictate morality on people, we get into Anna Karenina territory... Lines shift, depending on where we stand. Depending on the particular conflux of forces individuals try to survive, and hopefully even, at least for a time, thrive in. Mortality is hard enough.
So, um, about those movies? Sheer decadence? No, no. Look how cold it is! Movies take my mind off working out indoors. That's my excuse, and I'm sticking to it. We try to shift, shift, shift in the direction of being better individuals, better serving others and doing less damage to the planet. But there are no easy choices. Shut down all consumption today? Economies tumble. Livelihoods lost. So it is more a matter of finding the trimtabs that turn this big economic-environmental-social ship in a direction that is more sustainable... If...
1/9/14: Best commentary on the state of commentary ever?
2/12/15: Important discussion of the cost of flash social shaming via platforms like twitter: How One Stupid Tweet Blew Up
We Need to Talk
Is my writing style hard to understand? Should I try harder to simplify sentences -- I do tend rather to the recursive and pass by reference and otherwise make it hard to follow, don't I? But. For what I gain in color and nuance, do I lose too much in clarity and accessibility?
For example. In Enterprise Architecture: A Matter of Relevance, I created the feeling of Leviathan, which is also the feeling of being in an organization that has no clear sense of its structure, no clear narrative and purpose, etc. I did so to make the point that the enterprise architect has to sift all those signals in a "fog" of ambiguity and uncertainty for what is relevant, what is shapingly significant -- and draw those out. Yes, literally, even. Hopefully the last two paragraphs make that point clear.
But. I'd like to know what you think. Do I shed readers because I write in a way that is impenetrable?
I think there is room to treat readers like the intelligent curious playful people they are. But in an attention-taxed world, do I go too far, require too much?
1/20/14: Well, if it works for Faulkner? ; )
There is a point worth bearing in mind though -- I expect that links are followed after a trace is read, if someone is especially interested in the topic and wants another layer of meaning and is inclined to go find the "easter eggs" in the links.
Dances with Hatses
And this is why it's fun to have a dancer daughter:
"To exist is to dare to throw oneself into the world" -- Simone de Beauvoir
I write to see what I think; alternately put:
So, it is hard for me to not write, no matter how much I decide it crushes my spirit and ensnares my attention in protesting that this luminescent thing of a Trace is not nothing! I feel like one authentic, genuine, expression of appreciation would free me from the trap of wanting this thing to have been worth it (sunk costs are easy to tell others to walk away from; try walking away from your own, though). And I remind myself that mapping my journal is such an expression! That "amazing" is such an expression. That "may the trace be with you" is such an expression. Okay then. I can go now, right?
"This sickness, to express oneself. What is it?" -- Jean Cocteau
Some insist "the source is the design." Let's explore that position, for it presents a neat Socratic challenge.
When we look at our own code, or someone else's, and wonder "what the jabberwock was I/he thinking?", some of that is related to code understanding, which may be:
And some of that is design thinking that influenced and shaped, but is not expressed in, the code. The following is generally missing from the source (though, especially at narrow/local scope, may perhaps be partially inferred from assertions and tests or comments):
We might protest that points like these merely highlight what is missing in terms of retrieving the design thinking that went into the design. The design consequences are now entirely captured in the code. Or are they?
What is the point of considering "Why was it done this way -- what forces and goals and constraints made writing the code that way make sense, at the time?" We can play devil's advocate and say the design is what it is -- a POSIWID kind of point. But if we don't understand what system integrity means for our system, how do we maintain it? Further, in evolving the system, we want to assess whether the founding assumptions and shaping forces still hold -- does the design still make sense?
Likewise, we might protest that what we decided not to do is merely superfluous cognitive load, now that the system is the way it is. Except that we argue so much about better ways to do things, that for those that are make-or-break shapingly important, it is just as well to persist our reasoning so that we can recall and share it, defuse arguments perhaps, but also inform and persuade and convey the wisdom that went into the choices that were made. Not everyone will read it, but those seeking to grow their technical acuity and wisdom will.
Backing out further, as we begin to navigate towards an understanding of an overwhelmingly large code base, it is useful to have "big picture" map-like views of the system, that help us create a mental model of the structures and their interrelationships, and what they are supposed to do -- to channel our attention more efficiently, but also to have a level of understanding of the larger system, and how it works, so we have context for the pieces of the system we're going to focus on.
Design is the act and the outcome. We design a system. The system has a design.
The system has a design because implicit and explicit design intuition and reasoning shaped the system, steering it, or attempting to steer it, towards more the outcomes we want. Still more, the better we are at design.
The code is not synonymous with the design. It is a realization of the design. It is shaped and constrained by the design. From the code, we can but partially infer the design intent that shaped it. We can reflect aspects of the design that is embedded in the code, and this can be supported with code visualization tools (visualizing static dependencies among structures in the code, for example), but these reflections of what can be garnered just from the code are incomplete descriptions of the design.
Code can be used as a design medium -- that is, it is a medium for design thinking and design expression. Indeed, code is the dominant design medium for software systems. But that is not to say it is the only medium, nor for all purposes the best.
Code realizes the design that may be enacted in our heads as thoughts about what the system needs to do and how to accomplish it. And, as the code takes form, we interact with the design expressed in code and our shaping, reshaping, elaborating mental model of the design.
It is just as well to ask:
Systems are not "parts flying in formation, trying to be an airplane" (Wim Roelandts) but parts that interact and give rise to (emergent) capabilities and properties. Design considers and expresses how to achieve these capabilties with more the properties various stakeholders care about. Properties that include structural integrity and design integrity (including consistency or "wholeness" with that "quality without a name"-ness that comes from coherent design and not just a heap of parts duct tape and bailing wired together).
We have more options than just code for thinking, reasoning, analysis, tradeoff and alternatives assessment to enable us to come up with better mechanism and system designs. These include models and discussions (conversations and written), mockups and sketch-prototypes, simulations, and code prototypes -- as well as an incremental and evolutionary approach to systems design-building-evolving that we associate with Agile development.
Design happens at different scales and scopes -- it is fractal, if you like. And to see the design at larger scope -- the form of the system, its contours and surfaces, interactions and major flows, it can be helpful to express the design in a design language other than code. Code draws us to the details; requires a focus of comprehension on particulars that are dense and meaningful in their very precision. With code, every detail matters. That is not to say that no details matter to design at other scopes, but it is part of the art of design to decide, given a design element and its expression, which details matter. Any conceptualization takes in and leaves off -- we just can't hold all actively in mind at once. Code tends to pull us to a local view, implicitly leaving the system and even mechanism views out of the frame of focus. As we zoom out to wider frames, taking in more of the system and what it does where and how and why (because we must make tradeoffs), we begin to describe our mental model to ourselves, to make meaning and explain the system to ourselves, in a different language than the language of this or that operation, as powerfully transformative as any operation may be.
Our ideas are such small fragmented, partial conceptualizations; and even if we work hard to develop not just knowledge but wisdom, and apply not just wisdom but a determined process of finding things out through questioning-reflecting and experiment, we're fallible. The notion that we can get away with designing a complex system merely with code as the medium of design thinking, reasoning, probing, alternative exploring, on the one hand, and expressing, communicating, holding for future reference and evolution, and so forth, on the other... is... just silly when one puts it like that? We need to take different vantage points and use different frames-of-reference, and while TDD, for example, is a way to get us to shift our vantage point, other vantage points also help. Some are ad hoc, and chosen or designed to fit the moment. Others we step into as a matter of discipline, because we have found that discipline helpful across a range of contexts and systems.
Code: Necessary but not sufficient?
Expanding further on the discussion, as the-code-is-the-design goes, here are a few thoughts from earlier traces:
As code as truth goes:
I'd like to recommend reading all of that Code is the Design -- Or Is It? trace, but I'll pull out a few more highlights that help identify design thinking that shapes the code, to be sure, but is not extractable or generally inferable from the code by itself:
For an example of design description, principles and reasoning that is well conveyed with sketches (informal visual models) and textual description, see Martin Fowler's description of the LMAX architecture.
Here are snippets from other traces that reflect on how models supplement code, to help us in thinking through design challenges and approaches to addressing them, as well as to grok the design (of existing code) better, so that we can explain it, or evolve it, etc.:
One thing we tend to keep overlooking in our field, I suspect, is the difference between design-coding in a team of one or a very small team of people with strong communication among them, versus teams of teams. I know, I know. Best to do small things. But sometimes things are big. Not necessarily Dreamliner big, nor even hybrid car big. But still big enough that they take more than a few people if we want to get them done in competitive timeframes. Product lines. Systems of interacting systems. Various ways complexity and the need to have teams of teams enters the picture. Anyway, sure, sometimes we can do the design in our head as we're coding, and keep a mental model of the structure and mechanisms. But as more complexity enters the scope, we need ways to contend with the complexity cognitively and organizationally. We need to get the design activity out of our heads and into a shared thought space. Of course, there are a lot of traces addressing that topic!
1/20/14: Gene Hughson wrote a post which adds several useful points to the discussion (and it quoted me -- happy day! :-)
1/21/14: Design happens at different scopes (lines, units, mechanisms, ... cross-cutting concerns, system, capabilities and properties offered to the broader systems-of-systems, ...). And is to be understood at different scopes:
1/31/14: Software archeology and anthropology:
3/8/14: Sketching and design:
Architecture: designing across:
The point of design is mindfulness. Different techniques bring more mindfulness to bear at different points in the design process.
3/12/14: "Quality is a function of thought and reflection - precise thought and reflection." -- Michael Feathers.
Yes. But. Quality is not only a matter of correctness, or even correctness and how hard or easy it is to change at the unit level. It is about the qualitative experience of the system, from various standpoints (users in differing contexts, operations, system evolution/maintenance, etc.). So quality is also a matter of discovering what is valued, what delights, what is below the threshold of concern given the trade-offs concerned with reaching what delights and is desired, and what frustrates. That is, there is a whole lot of design thinking that is conducted in the fog of uncertainty that requires the kind of intuition and judgment we associate perhaps more with art than "precision." It may become more and more precise, but there are realms of thinking that is about leaps of intuition and judgment that is springing from the chaotic connection-making unconscious.
We use various design tools to get that thinking out where we can see it, so that we can nudge and move the design towards more the outcomes we want -- along the way, discovering more what outcomes we seek. That is, we are well-served to recognize that "quality" is not something discrete, but interacting qualities that each themselves are best thought of as being on (complex) continua. We can provide more or less features, We can cram more or less into features. We can make features more or less automated with more or fewer degrees of freedom to the user, we can make the system more or less scalable, areas of the system may have differing performance profiles. It isn't just one complex design envelope. So quality is a tricksy matter, and being very precise about one area takes attention. But there are other areas that need attention too. Precision is a good thing. Where and when it is a good thing.
So the tools we use to assist our design thinking usefully includes unit testing in the TDD sense. Along with visual design tools which also may be used with less and more precision, depending on the design thinking we're trying to support. For example, we can sketch sequence diagrams in very hand-wavy, sketchy terms, leaving lots of detail off, but simply using the tool to think about and surface responsibilities of the system, finding natural "interstices" of the system, exploring the key abstractions that will give shape to the system. Doing so in a sketchy feeling-our-way sort of exploration that is cheap to do, so a reasonable way to evaluate various alternatives and narrow down our choices for more detailed analysis and prototyping or whatever.
3/22/14: Perhaps pointing to Seth Godin at this juncture is an 'appeal to irrelevant authority" but... hey, it's cool to point to Seth Godin, relevant or not. ;-) So here:
4/3/14: Advocating code as design medium:
A couple of things come to mind. One is that much of our discussion about design in code circles focuses on the qualities or properties of the code -- the emphasis of refactoring. Sure, implicitly the code does something of value, and much technical debt accrues as we jump through mental hoops building the capability (which may be system, rather than user, serving) or function, focusing on what the code needs to do, and not on code properties. That is, we emphasize building capabilities and the related software qualities, and then (re)turn attention to code qualities and improving the design of the structures and mechanisms that deliver the capabilities (function and associated qualities of the capabilities) and qualities of the system as a whole. But design is not just about code qualities, nor even just about structural integrity and resilience, but also about the system providing value and being valued, even delighting its users, and earning returns. Revenue, or reputation. Whatever. That is, there are different faces or facets and interweaving threads to design. Emphasizing one should not imply we neglect to do others:
The other, rather different point: Our minds are powerful, but we expand and enhance our mental processing power by externalizing our thinking, so we can "see" it, get different access to it, persist it at least in some form, and others can access it. Some forms of expression give some kinds of reasoning more support than others. And this can be highly personal. Some people have a harder time thinking and expressing themselves visually (even when the bars are lowered to such sketchy imperfection as mine ;-), for example.
4/4/14: Other thoughts come to mind. The evident priorities (given the mess -- euphemistically? -- known as "technical debt") tend to be of the form: 1. build functionality (what it does) 2. figure out how to improve system/software qualities (how well it works -- in areas like performance or scaling) and 3. (when disaster looms?) improve code qualities (refactor). So the focus on code qualities -- that is, the design focus at the code level -- is warranted because design (of the code) tends to be such an afterthought (under the pressures of figuring out how to build the current delta of functionality, under schedule pressure and team co-commitments, so we move on, rather than refactoring as much as we might otherwise like, as we go) it is not done well. And needs to be improved, needs the attention of smarts and experience to draw the lessons out and share them, to improve the state of our craftsmanship. Now, we're building functionality and releasing continuously or at least often and getting user feedback so we have the functionality/capability design base covered with incremental design. Or so they say. I say not so fast. For one thing, we canalize, but anyway.
Design happens at multiple levels and on multiple fronts, and these interact, and the medium that gives us the best leverage isn't always code. Where it is code, we should use it for then our design thinking is doing double-duty in that it is also delivering the system. When tests are a great medium for the design thinking of the moment, then we should use those, because tests do double duty too. And the design expression of mechanisms and fundamental architectural structures can do double duty -- it not only gives us better designs because we have something to "move against" (we and others can see the thinking and explore alternatives), as it were, but it shares and exposes the design thinking so others can learn from and improve it.
Let's hear the refrain: Judgment factors. And factors and refactors.
7/27/14: When I wrote (in the trace above):
I wasn't in any way precluding "accidental architecture" in that notion. I was merely pointing to "design" having two substantial and different meanings (act, and outcome), which has implications for approach and medium (for example, are we seeking to support the act of designing, versus "seeing" the design in the built system). I illustrated the distinction with "design a system" (act) and "has a design" (outcome). Sure, this is the classic verb versus noun distinction that appears in the dictionary. The point was to rephrase in a way that helps us think about code as a design medium for the two different understandings of design -- design as act, versus understanding and communicating the design as built.
Of course, putting the two in close conjunction, does tend to prompt to mind the disjunction that occurs when systeml design is neglected, so that the system is pretty much a kludge of granular parts. In that case, the design may have been, for the most part, limited to design (thinking/acting/deciding) focused at narrow scope (like the scope of a class or function or some such narrower unit of abstraction and composition -- as opposed to system or "subsystem", etc.). That is, there is still design going on, but not explicit system-scoped design that contemplates and designs for system outcomes, such as system properties -- emergent properties that arise from interactions among the parts, not just the parts themselves -- and system integrity. We'd characterize the resulting architecture as accidental. And being accidental, it may not do a particualrly good job of supporting some key intended outcomes; may even prevent them. This points to the importance of having a notion of design happening at different scopes of impact (ranging from unit to system) which gets us back to code as design medium -- while good as a local design medium, it doesn't particularly support reasoning about (all) system properties and resolving tensions and tradeoffs among them.
Anyway, what I was going after in the trace, was getting us to ask how well code supports design reasoning and expression. Clearly it does a great job of building systems, and a more or less sufficient job when it comes to design reasoning and expression given that it is often the limit, perhaps supplemented with a rough sketch or two, of the design tools we use to give ourselves some cognitive assist and to communicate and express our designs to others, not just the compute systems they run on. But relying solely on code means we lose some design information and we arguably don't give ourselves enough cognitive assistance given the complexity of our systems, and the myriad competing tensions and dimensions we need to weigh and resolve and better address. The F-35 is a case in point -- complex systems can't be approached as merely many, many "parts flying in formation, trying to be an airplane" (Wim Roelandts).
1/5/15: This image from Shadows of the Mind: A Search for the Missing Science of Consciousness (Roger Penrose) and this on models of our mental models have their pertinence. And there's this: DDD - Diagram Driven Design (Gregor Hohpe).
Experience becomes history. History, context. Amd context shapes -- confines, constrains, orients, yields potential.
That reminds me, I wrote a few things:
One way of thinking about it, is we need software architects because software architecture. Smiles. No really.
We design to get more the outcomes stakeholders want (Herbert Simon). We undertake to apply conscious purpose, or intentionality, along with experience, knowledge and insight, and design techniques that aid in surfacing and resolving design demands and tensions. In competitive situations that characterize business systems and products or services, we're designing systems that tend to be complex in that they forge new frontiers, innovating to provide differentiating value. That is, they are not only composed of non-trivial components and interactions, but there is considerable uncertainty as the design envelope is explored and pushed, and contexts of operation and use continually shift and evolve. Hence, we want our architectural design process to support agility, integrity and sustainability.
Agility has two essential components -- sensing and responding (or spotting and exploiting). Sensing opportunity, including opportunity to create and define value and opportunity. Sensing threat (uncertainty, change, unmet needs, escalation or drift into failure, ...), and sensing when and how to turn threat into opportunity. And responding adaptively. Which itself has various facets: what is done and how. There's an element of how quickly (under threat or to take advantage of windows of opportunity), but also how we respond can severely undermine our ability to respond adaptively in the future -- the near future at that.
By integrity, we mean:
By sustainability we mean sustainability (or the ability to thrive not just in the short term, but to continue to do so well into the future -- including a "bounce forward" resilience) in all its senses, including:
Thomas Cagley has been exploring technical debt with a series of posts:
Gene Hughson wrote a nice post:
I've written many nice traces:
What? They aren't nice? Or you don't like that I say they're nice? Well, shoot, someone has to, and since no-one else is kind enough to, I guess that just leaves me. Aaa-gain. ;-)
Even if you don't think my traces are all that nice, you have to grant that it is nice that in them I mention other useful work on technical debt, such as:
Waxy build-up, huh?
Technical debt as house of cards:
Brian Marick is wonderful and very knowledgable not just about software, but literature and other areas too. But...cybernetics died? Who knew? ;-)
The software world can get so focused on the details of language structures and clever manipulations that it misses what is happening in software and systems architecture.
Pst. Among friends, cybernetics is not dead. Pass it along.
1/21/14: 'The greatest deception men suffer is from their own opinions.' -- Leonardo da Vinci
Oh my, it seems a lifetime since I read Howard's End. Reading this, I know what's up next for me to (re)read:
Image source: the internetz
There is growing awareness that though we have come so far in terms of inclusion and opportunities for women in the workplace, we have a numbers problem in tech that hints that something is not... quite... right... Those of us who enter and stay in computing love it, but why do fewer women enter the field, and why do so many leave mid-career? Here are a few of the explorations of this emotion-triggering topic:
I think this is also illuminating:
Given the numbers, and given that many women have what it takes to love this industry, but shy away, it is worth asking: Do we make women feel welcome, comfortable, like women belong?
What makes women feel like they (we!) don't belong? Condescension, lack of inclusion, ignoring their (our!) presence, input, work. Now let me hasten to add, that this isn't generally about obvious obnoxious behaviors -- those are relatively rare, but they do serve to remind women that the threat to women who stick out is there. It is more the subtle massing of small ways in which people don't respond to us when we do speak, for example.
In its worst incarnations, not welcome looks like this, among other things. Men get trolled too, but not as much with the physical threats, and contact info being spread along with slurs and calls to do harm. I'm not kidding! But there are many incarnations. And we're so often told that men are subjected to the same stuff -- while it is just as important to raise awareness of the ways men are also diminished by downsized expectations and harmful innuendo, it can also feel like we're being told that we're being whiny and can't play the game how its played. Instead, can't we all use the pain of whatever degree we have these kinds of experiences at, to have more empathy and engage more positively in making things better for women and men, and girls and boys. More inclusive. Less harshly combative. Not disallowing horseplay, for it is important. But also noticing more when gentle people are being pushed aside before they are driven away because they don't, wouldn't even know how, to engage that way. Women are told to be more assertive, but messaged in a myriad ways to not be. That alone creates an uneven playing field for career momentum unless we start to bring facilitative leadership strengths more into our value-set, to counterbalance the success rates of those with more strong dominance hierarchy behaviors. It shouldn't be about not valuing the ways that some people just naturally project assertiveness (voice, height, body bearing, strategic cursing, ..., "making an example of" to mark territory, etc.) but about recognizing that other styles can help teams and organizations be great, too. If we just remind ourselves to include others more, and to ask quiet people for their input, for example, we start to break up the lines of inclusion/exclusion.
3/7/14: It might be helpful to consider the ways you feel you don't have a voice or aren't heard, and where that comes from. Gentle boys who have avoided being bullied. And so forth. And then use that as a basis for understanding how that might be true for women or minorities in any situation. The more vulnerable, the more likely they are to have been taught some lessons directly, by innuendo, of by seeing examples made of others.
1/22/14: It's not just STEM...
Sorry if raising awareness raises discomfort... but... Well, for example, the line-up of speakers before the call for papers, sets tone... Like this. I don't think there should be a shipwreck over it, but it'd be nice if gradually gradually more of these men in the line-up, for example, would suggest women speakers to the conference organizers. They ought to know some good women in the field, if they are paying attention. No-one should be called out (to be shamed), because the issue is pervasive. Unintended instance after instance after instance, adds up; in each case, organizers are pouring a lot of hard work and good intentions into a great experience for audiences, but doing so without realizing the social cost of not creating inviting space for women's voices to become associated with technical authority. But if each person who becomes more aware of the way they could pitch in and help shift the ratio, does, we'd see the trim tab effect of their leadership.
1/23/14: This just in via the Serendipity server (aka Twitter):
And this from yesterday, via Reginald Braithwaite:
I know, I know:
We're raising awareness, so we can together make this a more wonderful world. It takes talking and writing about it though, so we get to understand each other's experiences and perspectives, where it hurts and frustrates, where we can reach out and help. We talk about it, to change it. We try to expose the truth, to reshape the truth when it will help us be more the humanity we want to be. Words are an instrument of peaceful change, for they help us become aware of actions we can choose more to take. Habits we can try to regroove and shift away from. Martin Luther King and Nelson Mandela helped us note and reshape fundamental social truths. We still have a long way to go on race, on gender, on socio-economic grounds, on freedom to love whom we love and to be ourselves no matter what body we were cast in, on age, and more....
A few points. Even if the numbers were accurate, 2 rape or sexual abuse case per 1000 per year (and 4 per 1000 for younger women) is not dismissably rare... Moreover, there is data like this data sheet from the CDC and "1 in 5 women in Indiana have been victims of rape at some point in their lifetime!!"... Know too that many incidents are not reported, and more are close-calls that teach/remind women the risk is real. I could tell you a story about ECOOP'97 for example.
As for the issues around sexual jokes (e.g., in conference presentations), I have tried to make sense of why they tend to be a problem, and this is my conjecture: when a woman (or female parts) is the object of the joke, or where the language subliminally carries innuendo of sexual aggression against women, then women are being implicitly placed in the "outsider" role. When ridicule or subjugation in some form is the object of the joke, it can be a dominance or territorial marking behavior that distinguishes insiders/belittles outsiders; you'll find this often enough in political settings to rally support against the opposition. Transfer the behavior to gender in a professional setting, and we wonder at the implicit messaging? Even if we find it funny, the smack of exclusion strikes women. Moreover, "male gaze" imagery and language implicitly caters to hetero men in the audience and draws a boundary along (heteronormative) gender lines. Not all women will be aware of these messages, and men who are subjectively being demarked as the buddy-buddy-insiders to the joke and/or imagery may not notice it either. Leveraging locker-room styled male bonding through horseplay and sex jokes in this way, may make some women feel more included -- they have been allowed into the locker room. But make others feel excluded -- their gender is the object of the joke, and all the other exclusions gets exacerbated by that exclusion. Personally? In settings where racy jokes or imagery put a blinking arrow over my head as the only woman in the room, I get uncomfortable because I didn't ask for or deserve the attention on the basis of being the one who is different in that way. I get the jokes; in a setting where various golden calves take their fall under the hammer of humor, I'm game. I think camaraderie-building is goodful. Still, I would prefer that where I get attention for being different, it is for the substantive contributions I make -- albeit in a different style, with a different voice. With a gentler style and softer voice and smaller body frame, there is already a huge autonomic expectation deficit that I have to surmount to be even on the same playing field as most men in terms of having any sort of authority (meant positively, in a respect for contribution sort of way) in this field. To be further rend as an outsider by jokes or images, puts me at even more of a disadvantage.
Notice though, that this is relative -- if women weren't so much in the minority (to the extent that I am frequently the only, or the only other, woman in a large group of men in technical settings), the dynamic would possibly be very different. It is hard to identify how the mechanism works; I gave it a shot. Perhaps I got it all wrong. [see 3/27/19 footnote]
I don't want this trace to be the one that gets talked about. My Trace represents 8 years of arguably excellent discourse on architects architecting architecture -- that it has received so little attention has to be one of the atrocities of our field? Oh, that's just a little dramatic hyperbole as ego-salve, she smiles teasing-wryly!! Anyway, it would not be fair to make a victim of me for this attempt to raise awareness by touching just a gentle ripple of insight among those few who chance to read here. ;-)
10/28/14: I too am on a journey, and there are many lessons. One is that I play a role in the experience of other women, and at first I had to pay attention to paying attention to other women in our field -- to following women on Twitter, to "hearing" them -- noticing their tweets and following through on their pointers, reading their work and giving them a more even playing field in my own attention space. And it's not just women -- I try to attend to, to notice, to hear, to pay attention to a diverse set of people in our field, and especially people of color and other URMs and people subject to various prejudices, biases and discrimination. This standing together, made it easier for the aggressors to get away with their harassment and even rape. We need to change that/that is what we are working on/through, when a wave of "reaction" floods through the twitters...
3/27/19: Soooo, I realize that the othering and outsidering is only part of the story. We're all learning here! I went from observing that "rape culture has real consequences in women and girls being raped in serious numbers," to "objectifying women in jokes makes women outsiders." Connection missed! These jokes land differently on women who have been raped or threatened. Further, what we normalize, or at least don't firmly place outside the norms of a community, doesn't discourage and prevent. People telling their stories over the past 5 years has made something very clear -- our individual stories were not isolated, rare incidents. They are way too common, and way too much a feature of a professional landscape that doesn't only discourage women through exclusion with joking references that objectify and belittle women, but through the amount of actual violence reminds women that the jokes have undertones of real threat -- they normalize behaviors, suggesting that men through male bonding on objectification of women, don't stand with women against rape and sexual harrassment.
When the tenor creates a context of implicit acceptance of boundary-breaking behaviors, weird stuff goes down. The current "learning moment" is challenging us on "where should the boundary be" (hint: listen to those who understand its impact). Back in 2007, Hugh McLeod created this cartoon at SXSW, and I expected there to be some conversation on implications. Nadda. Zip. Not a word. I couldn't believe I was the only person who'd noticed not just the casual suggestive underlay of conference-as-hookup venue and what that does to safety, but also the casual way women were reduced to a body part so that the person is no longer in the picture, and... even though the surface meaning is "we're adults who enjoy our sexuality," the verbal association with killer is scarier for those who have reason to fear. So, sure, we can say "we're adults and this is art, and we must not censor art." I'm totally on board with not censoring art, obviously. Still, put this in the context of a professional conference (albeit one with an emphasis on tech+art, with a side of partying), and make it an accepted part of the discourse, and it weakens expectations about boundaries. And this from 2009 was one of the low points of our field. (It's bad enough to objectify a speaker during her talk, but to do so on the public display behind her, for all in the audience to see... as I said, a low point.) Over time the past few years, more stories have come out. These are just some of the kinds of things that have been happening.
Oh yeah, as real service to you goes, I need to catch you up on some of the movies that worked out my mind while I worked out my body these past evenings. :-)
I'm looking forward to more Robert Bresson, though it looks like we'll have to buy them on DVD as Netflix/iTunes/Amazon Instant are all abysmal when it comes to great foreign movies. (We have The Trial of Joan of Arc and I no doubt told you about that last winter. :-)
Why tell you? Why quid pro quo my dear Watson. (Paul Harland recommended Bresson -- indebted I am!)
As recommendations go... The two young gentlemen at the checkout counter at the grocery store yesterday asked me if I had anything fun planned for my Sunday. I was so taken aback I couldn't think of what to say! So I told them that I don't always plan fun, and that at 10pm the previous night my teens and I had decided to watch Witness for the Prosecution. The young man packing the grocery bags strongly encouraged me to see Shame. The other young man recognized that my teens probably should see it, but they probably would not want to watch it with me. (I hadn't mentioned mine are young teens...) We didn't catch 12 Years a Slave in the theater, much as we wanted to -- hopefully it will make another circuit as Oscar fever mounts.
And so it goes. Life.
1/20/14: I hope you noticed I gave the director names along with the movies. Think architect. Think body of work, aesthetic and PoV/stance, as well as shaping force bringing integrity to the work. ;-)
When I read
I was reminded of:
And in particular:
I pointed Chad to that article, but I should add that I believe that good movies have the same effect/benefit of stretching our imaginations and empathy capability. Why good literature and movies? Because simplistic pulpy fiction or movies may not leave much to the imagination nor delve into complex situations. They may be camp and challenge that muscle. They may be full of pop culture references and challenge that connection-making facility. So I'm not discounting them out of hand. I am rather making the other point that great art -- literature, poems, movies, pictures, music -- doesn't tell us in a spoon feedy way what to learn. Good books and movies, especially, explore the human condition in all its weird messy nuanced half-truths, its glory and shabbiness, the complex ways that things don't fall cleanly into good and evil. They present complex situations with their many interacting forces and fraught moral quagmires and the thoughtspace of protagonists and others as they encounter what they feel and glimpse, their tensions and hard choices in the fogs of uncertainty and pain loss stirs up, and so forth. They invite us to discover by actively entering into and engaging with the work, to find what it yields to us. Prescriptive writing, which may even be strong in colorful rhetoric, aims to guide us, tell us what to think and do, while great fiction offers situations in their complexity, offering us scope for trying out other viewpoints, giving us the chance to change our very minds! It is very much an interpretive interaction between our minds and what we are open to discovering. Empathy is such an active stepping into another's situation, using our imagination.
The last part of Chad's well designed, thoughtful, helpful post, reminded me of this xkcd:
which I mention in a trace on Gestalt Principles. And yes, yes, indeed, I have traced on empathy:
Empathy is also treated in:
Others on empathy (videos):
And in IT:
Oh, and since empathy is flavor of the month, there's even an HBR blog post on active listening that is titled:
And this just in:
Empathy is hot! Doesn't that just make you want to go back and read The Art of Change: Fractal and Emergent so you'll know what else is about to be big? ;-) (Oh, I know all about cognitive biases and "what we're paying attention to shapes and determines what we pay attention to" -- I said that one before cognitive biases were hot. Yep. Hindsight bias. ;-)
Now, back to the movies:
1/22/14: I found these snips (from Why fiction is good for you) relevant and interesting:
1/22/14: Bacon on reading! Yesss!
1/24/14: Via Paul Harland:
1/27/14: This, vis Joyce Hostyn:
3/22/14: Three types of empathy: Cognitive, Emotional, Compassionate
4/3/14: Neat overview of research and some counterpoint:
Empathy in Practice
Dashboard on the Boxes we stuff people in
Well, as empathy goes... I pointed to my Martin Luther King Day trace from a few years ago. I know. It's not bright shiny new... But stereotypes such as those in this cartoon show why it is still needed. I know, I know. I've traced:
But that is a lot different than a cartoon showing a girl with no thoughts, and only loads of textured babble... I realize that the cartoon just struck a chord with someone whose daughters effusively bubble sparkling delight. He no doubt is quite charmed by that joyful chatter. But still! A cartoon that reinforces and draws forth the notion that girls have no thoughts... they do no thinking... Just babble? That is wrong!
My Martin Luther King Day trace does shine (in reflection, by quoting), and shine a light, doesn't it? Empathy? And kindness. It is very hard for me to break taboos against women self-promoting by tweeting a link to a trace. So when I do, I feel exposed and anxious about "doing it wrong."
Now if I was drawing that cartoon, I'd draw the thought bubble with people and things and relationships (connections but also investigating how they work) among the people and among the things and to the people, and relationships among the relationships. And the talk bubble as lots of positive bubbly effusive things being exclaimed about all the cool things she is learning, even as she muses out loud, and relaying so others can share the discoveries and joy. Girls are complex creatures with complex thoughts darting all over their beautiful minds. It is not fair to trivialize them or their minds. Cartoons are cartoons -- an artform, often satirical, that amplifies things that are right and things that are wrong about the world. They announce the human condition to us, often via irony and subtle devices. But in this case, apparently the condition being spoken is one of a mind left empty by all the babble. Tsk tsk. <Steps off schoolmarn soapbox and looks abashed.> ;-)
Image source: Thanks, Mom and Dad, for all your support, New York Times
1/22/14: I know. 7 year old girl's poetry. The courage it takes to trace and tweet that.
[In case you wondered about the muse -- that poetry writing kid now composes and writes songs. And the content of her mind? She also competes in the Science Olympiad and, as a middle schooler, is doing honors classes in science and math in high school. Along with being in the highest level of precollege ballet. My son is amazing too, but he is much more of a private person, so I try to respect that... Except when it comes to deCycles. I have permission to brag that, sort of as a public service to the awesome people who make it happen, and because it is a way cool thing for teens to do. Anyway. Proud mom, I are.]
Paul Harland returned from a blogging hiatus to write a post about abstraction and The Art of the Talkie. It's a lovely post, but I'm going to pull out a piece that fits my agenda just now:
That post was rattling around in my thoughtspace when Kevlin Henney tweeted:
If you're in the architecture space, you've likely seen reaction to the "non-functional" term before -- for example, the Clements et al SEI team have long been advocating for the term quality attributes (their first book on software architecture dates all the way back to the 90's). And Kevlin's version is vivid and witty and fun and acute. Point taken. And yet.
Stepping on the stage for a little counterpoint for entertainment: Inflammable anyone? The technical meaning is opposite to what we'd expect, given flammable and the prefix "in." But it gets messier. There's plenty of precedent for auto-antonyms (or contranyms). Take left, which can mean "to depart" or "to remain." So words need to be interpreted in their situational context. (That phrase is from Sara's song. I couldn't resist -- I love it!)
While I agree that NFR isn't the most evocative term for what we are going after, it is in common use, and it is the hand-me-down use through generations of projects that informs our interpretation. Sure, we, too, map from NFR to alternative terms like quality attributes (or qualities), properties, characteristics, and for a space of the qualities, service level and SLAs. And I, too, make a bit of performance art of the low-hanging fruit joke that NFRs don't refer to dysfunctional requirements... (Though we might explore acceptance boundaries or minimum thresholds on qualities by considering what falls in dysfunction territory.) But I'm also perfectly comfortable if an organization wants to retain the legacy NFR terminology that is well understood across their various disciplines (hw/fw/sw) and teams. (I gained much of my understanding of system quality definitions working in product development, where NFRs were approached with non-trivial insight and treated with engineering wisdom I hope I absorbed sufficiently.)
If we squint into history, we can infer how the term came to be used this way -- if we think of the space of requirements as being all those that are functional and those that are left, that then are not functional, or non-functional.
Still, some qualities relate to functionality (what the system does) from the user's perspective -- they are the "how well" dimension (like performance, and usability). Other properties relate to characteristics that operations cares about, like scalability. Others relate to characteristics of the code that the development organization cares about (like understandability, testability, reusability, etc.). [So we distinguish between software qualities (operations and use) and code qualities (development, evolution/"maintenance", product family extension, integration into solutions or systems-of-systems, etc.] That is, non-functionals, or quality attributes are attributes of the system that impact the developer, user, operator, and other stakeholder's experience and sense of the quality of the system (where some attributes relate to the system in operation and use, while others relate to the code).
While we're at it, we might want to make a little memorable educational performance art of outrage at the term "requirements." ;-) For really, these are, generally speaking, matters of design and strategy, not precast or preset in the situation. In many cases they aren't required so much as judged and determined by someone (or several) to be what is going to be asked or expected, and they become "requirements" by decision and action. Sure, situations vary -- if you're a contractor in India, you might get requirements thrown over the ocean at you that you're expected to deliver to. etc.
Whether we call them non-functionals or qualities, and requirements or design decisions or design commitments or some such, what we're going after is a set of system capabilities with associated properties that form a design envelope. Qualities are continuous (the "landing zones" metaphor is useful), multifaceted, and interrelated -- getting more of some will interact, perhaps counteract and intervene, with getting more of others. And there are constraints to take into account, like budgets. And from the conflux of much, the desired commitments or requirements are determined. The reason to make a song and dance of this, is that these design determinations take design savvy -- require not only a sense of what they entail and imply for the system, but also for what they entail and imply for users, operations, developers, the business. If we think these are simply requirements to be captured, we can weight consideration of a user, or some users, in undue ways, observing what they desire and aspire to have, but not taking much else into account. We need to be thinking of how we craft the "problem definition" (what we have tended to call "requirements", but which we lean towards calling capability design or system-in-context design) as being one face of the design problem, with "solution definition" (architecture) being the other face -- with interaction between both faces of system design.
Those who don't pay any attention to qualities and design intentions or design goals, fall into best-effort engineering and whatever that happens to yield, with tradeoffs being made under some combination of instinct and wishful thinking.
So, I kind of veered off into characterizing qualities in their contexts of relevance and concern as an example of the tricksy business of words that are best understood in their contexts. And while we want to get enough understanding of desired qualities to engineer systems with the integrity we need to deliver, it doesn't do to get our knickers overly in a knot about precise quality requirements before we know what design tradeoffs are even in the ballpark. I'm happy if the field shifts to a different term and ditches NFR. I think we can manage just fine even if we don't; there is a firmament of context-sensitive understanding around the term non-functional that demonstrates that even if the word is counter-intuitive, many have found a way to nonetheless make it functional. ;-) The bigger issue is working better with qualities and design of the system, from concept through capabilities and system-in-context design to internal design of the system and building out more what we want and expect to get -- even as we actively discover what it is we want and can manage to build in what sorts of timescales*.
I know, words can be like windows -- we don't notice them, but they frame what we see. So we need to be careful to use words that help us do what we're trying to do, rather than push against or subtly subvert.
Words, and requirements, aren't hard cast. They shape-shift, and change over time, but also across contexts. Yes, we can get better at defining them, and at different points in the design cycle, we bring them into clearer focus, disambiguate and clarify at least what the minimum sufficient and target levels are. But especially early in the lifecycle of a product genre, and even early in the design cycle of a new product (or system or service), we should also expect to work with ambiguity, and goodwill, rather than wilfully misunderstanding or obstructing understanding. Pick which frontiers to advance, and which to accept as good enough.
* Words have to be sequenced; please don't read "waterfall" into the fall of words there. The activities are interwoven and interleaved, as fits the extraordinary moment, its challenges and the outcomes we're working towards shaping, understanding, and build-delivering. In some settings, for example systems with mechanical and electronic subsystems with firmware, more may need to be done earlier to set context for the teams. Those cases where prior generations of product set a background level of expectation for capabilities and associated qualities (braking distance for cars, for example, has a threshold beyond which braking performance would just not be acceptable), have a different starting point than first generation, highly exploratory systems.
1/24/13: As performance art goes, here's a quip: Outrage over the subversion of language is literally everywhere. ;-)
1/24/14: I'm happy for someone (else!) to lead the crusade to change what word is in de facto practice for system qualities (or quality attributes) or properties or non-functionals. Still, I think we have a lot of work to do, to get better at characterizing qualities for our system under design (and designed-evolution). We need to better understand when and how to get precise. How should we characterize what system quality levels we want (to aim for in) for our system, taking into account that we need to shape understanding of what the qualities mean for our system (e.g., what does usability mean for this system) and resolve many interacting forces that come into play when we demand higher and higher degrees of qualities?
We can draw attention to this territory with some performance art (don't get me wrong -- I think performance art is very important; consider Randy Pausch and how he used to take a mallet to a brand new VCR to make usability points in the first lecture of his CS classes; if you haven't seen The Last Lecture, it is time!). I want focus to be on understanding that we're making judgment calls about which qualities to put the lense of our attention on*, what they mean for our system, how they interact and resolving them so we get more of what we want and less of what we don't want.
Judgment calls? Yes. We take into account what users value, desire, aspire to and such. We take into account what frustrates them. We take into account users in varying contexts. We take into account expectations set by prior generations of similar products and what competitors are doing, as that sets expectation benchmarks users and buyers and media reviewers will have in mind. We're taking into account (anticipated) load (e.g., transaction volume) on the system, and patterns of load (daily, weekly, seasonal). Threats. Capacity. And on and on. And if we're savvy, we use judgment as we determine the desired quality envelope for the set of interacting qualities that are significant for our system. Knowing too that what we focus on, will then cause other qualities to potentially raise their heads as more important than we'd noticed. And so it goes. To ignore these things is to allow happenstance to have rule. We want to apply our knowledge, experience and wisdom to getting more the outcomes we want, systems that delight where that is important, and satisfice where it is not, and such -- that "use conscious purpose without wrecking everything." (If you haven't read John Gall's paper with that title (.pdf on Tom Gilb's site) yet, it is time! ;-)
For me, drawing attention to being more precise about the word we use, while making the point that we need to use judgment about how precise to be about characterizing and setting desired quality levels for the systems they're defining, feels incongruent, so it's not a battle charge I choose to lead. It is all a set of judgment calls. No nailed down rigorous predefined set of engineering decisions that simply have to be stepped through. It is design. We take guidance. We apply experience. But we still have to develop and use context-sensitive judgment.
Does that make sense? I'm saying I recognize that the meaning of the word "non-functionals" in engineering contexts is incongruent with what we might expect from its dictionary definition (Concise OED at that). But there is another incongruity that concerns me (more), which is what would arise if I wasn't comfortable with that word-level ambiguity, but asked people to be comfortable with the ambiguity that surrounds qualities. We face a tension between getting really rigorous on defining and setting "requirements" for qualities, and allowing that they are design factors that are squirmy, squiggly beasties. And we must be comfortable with that tension, pushing for resolution and precision in some places, and accepting good enough characterizations in others -- knowing that more will become clear as we experiment, (iteratively and incrementally) build and deploy into use. Does that make sense? We discover what really matters. We try to discover the really critical bits as early as possible, bring all (smarts, experience, research, etc.) we can to bear, and then still discover more as we go. In part, because the context(s) into which our system is situated, is reshaped by the very system, but are also undergoing other changes as well, reshaping expectations and desires, and.... Uncertainty. Yeah. But we have to use judgment, to "create ground under our feet" (Dana Bredemeyer) that we can make progress on.
Image source: xkcd 1322
Doing a domain search on judgment on my Trace, the following are among those that come up:
And I'm reminded of:
3/10/14: More traces on word matters:
3/14/14: If we are creating a "me too" "copy-cat" product, then, sure, the competitor's product is our design starting point, and we have benchmark quality and cost profiles we are then working against, to differentiate. But being in the business of creating "copy cat" (or, more pleasantly put, "early follower") products, is a strategic decision, and while the design space is more constrained by that decision, there still are tradeoffs to be made in deciding which spot (capabilities and associated qualities, with a cost profile) in the feasible design envelopes to target. And as soon as we try to break out of the nose-by-nose race of cut-throat me-too competition, with innovative capabilities that launch new frontiers or form new niches in the market, we are back into the terrain of wider design freedom -- where design initiative has to be taken to explore and discover and determine qualities that matter and, as we reach for more engineering precision, set targets for critical qualities that market success hinges on. (Having a clear sense of the threshold of qualities below which we'd experience the system to be dysfunctional, makes for an interesting spin. ;-)
Via Paul Harland:
3/23/14: You might find the notion of "conjoint design" useful to have in your lexicon. I did some case study writing on conjoint analysis for Bill Lovejoy when I was a grad student at Stanford. That takes me back! Early nineties!
3/24/14: See also
6/5/14: "how well" should give you a Tom Gilb echo. :-) Tom Gilb is one of my "go to"s when it comes to system qualities. The SEI is right there alongside, of course.
I returned to this topic today, because Tom Gilb re-re-re-invited us to this year's GilbFest. It has been ever so long since I saw Tom.... waaaaaay back in the 90's when I was still at HP and we were working on Team Fusion (brining EVO, architecture and dynamic, organic teaming into Fusion). Dana has dined with Tom in Norway in recent years, but for me... way too long.
Yesterday Dana was talking about his ideas for what he'd do (at GilbFest). And it set me to thinking about what I could contribute, were I to manage the logistics and be there too. Which had me rereading this trace. Dana said something wonderful I don't want to lose track of -- he said "each person has their own well they go to, that gives them energy." Each person is drawn uniquely; they fill their vitality buckets at their own unique fountain. So each has different strengths and predilections, but also what they focus on, attend to, what compels and energizes them, is different for each. I think that well or fountain image is wonderful! But how does it relate to requirements? It sends me in different directions. Different people willl thrill to detail, others may be comfortable with the foggy ambiguity of early value exploration and discovery. Etc.
Repeating myself but again, what we're paying attention to, shapes what we perceive and pay attention to. So, of course, I noticed this:
Which, of course, I relate to the SEI's quality attribute scenarios (for NFR characterization/specification):
I've always found that wording to be a bit.. obtuse... Context, event and result works well for me.
"For example, a modifiability general scenario is:
And a reliability general scenario is:
* When we decide to prioritize and emphasize certain qualities, we draw design and implementation attention to them... which causes others to get less attention, and potentially that will come back to bite us... Thems the breaks kids. ;-) You remember the drill: Judgment factors. And factors and refactors.:-) This is why architects need to practice stretching -- system design is a dance with varied devils in the details, and other beasties. On the heads of pins. I tell you! ;-) It's not for the faint of heart, nor the dull of mind. Lots of arrows pointed at us, and the need to develop resilient self-healing egos. Among other things. But now I digress into qualities of architects. ;-)
Yes, that is a play on words.
Sure, as a system matures, we understand its demand profiles better and better -- but keep pushing them, so there continues to be novelty and uncertainty, even as regions of the system come under more control from better design understanding (how the mechanisms really work, under interactions with other systems and various operating environments and uses). Consider:
There is a lot going on there... Early in the lifecycle of something so complex as an F-35 with all its interacting systems(-of-systems), integration yields issues and emergent properties are discovered... to have been misunderstood...
Yeah. And. This wasn't in my requirements:
Fortunately Reddit is still up, so we can still talk to and about Google:
1/30/14: Google on what happened:
Image right: Richard Feynman, iconic performance artist-scientist ;-)
Ah yes, mentioning Randy Pausch and performance art, reminded me of this anecdote about Steve Jobs (via Dana Bredemeyer, via an architect in a workshop, but this version will do):
An example of performance art? Or just a performance? Regardless. It made the point... uh... vigorously...
1/26/14: Oliver Wendell Holmes on performance art (not that he put it quite in those terms, but still):
Ye-esss... I have characterized my Trace as performance art; what a good memory you have. ;-)
[This continues the "non-functional" discussion started above.]
I watched Richard Cook's "How Complex Systems Fail." The story about pumps (around minute 8+) illustrates that "requirements" involve active imaginative exploration of scenarios to discover what might and likely would happen if this design route for the system's interactions with its context is taken, versus another. It is a matter of making assumptions (and surfacing them) and playing out what transpires -- in a "future" world in which the system is "in place". Sure. prior generations of the (kind of) system help illuminate expectations, intentions, assumptions, and contextual constraints, but the context changes. And the system, with its changes over prior generations, reshapes and changes the context. For example, if the system is "smart" and means less human intervention, that has reshaped the context. You can see how that would have gone in the case of the pumps. Anyway, I highly recommend the talk by another MD (Richard Cook) looking at how systems (don't) fail. Another? Yes, remember John Gall and Systemantics?
The story told in Gene Hughson's post, Risky Assumptions and the Assumption of Risk, surfaces similar illumination. We make assumptions about the system, but not all are explicit, some are poorly conceived, and some are not even considered. Some of the assumptions lead to formal agreements or commitments about what we will/must deliver. We call those requirements. But we also tend (post hoc) to call those we missed or got wrong, requirements -- for example, when we failed to understand the operating context of our system, and what that would mean in terms of demands on the system, we point to requirements failure. These are design decisions that have to do with system capabilities and qualities, though they may be determined by choices we make as we code, if they haven't been thought through in advance. And so it goes. Yet we can't think it all through in advance. Hence iterative and incremental -- and interactive. Using the design medium that best fits the moment we're at. Which might be code -- building capabilities to better learn what quality levels we need to shoot for, and to learn what functionality we need, even. But might be role play and developing scenarios. And user experience/customer journey maps. And. So forth.
1/28/14: Anyway, I'm arguing that it is all design. If "Steve Jobs" (the handle we associate the innovation with) took playing CDs as a "requirement" for portable music, the iPod would not have come into being until someone else opened up the design space by tossing out that "requirement" (which, you note, was actually just an assumption that was constraining the design space). "Steve Jobs" (himself, and all the teams who worked with him on the myriad innovations in the ecosystem that Apple initiated and facilitated and built out) didn't just open up the design space around the player, but the whole set of ecosystems surrounding music and electronics and more. I'm using that example, because a vein of push-back is of the sort that points to existing physical constraints or strongly held expectations about how things are done. Disruptive innovations help reveal the relationship between assumptions and requirements (where requirements is the design of system capabilities and qualities), and assumptions and design of the system (internals -- parts and relationships; mechanisms and how it works, etc.). Hence our language: context, system-in context and system, and strategy and context; capabilities design and system-in-context; and architecture and system. Presumably you're going "I see what you did there" -- you just got rid of the need for the "requirements" word altogether, and NFRs along with it. ;-) Tee hee. Watch this woman. She's sneaky like that. You feel a little breath of wind and look around and without even knowing it you're seeing the world differently. ;-) What's that? Sleight of mind.
Ohhh. I know. Sometimes the design space is constrained by other systems our system must interact with, by expectations shaped by prior generations of our systems, and/or our competitors. Not to mention physics... Yet, if we engage in "how would we like this to be" rather than how does the past cast entrap us in assumptions we aren't willing to loosen the grip of, we open up the space of opportunity. We want to make design decisions which set direction and constrain future decisions. But the point I'm making is, do we let the environment dictate these decisions without question? Or do we give a moment to considering what opportunity we close out? The difference can mean becoming a Nokia or a RIM to Apple... Y'all, the assumptions our worlds are founded on are being reinvented! Re-invented I tell you!
And, quips aside, I don't really care what we call them, so long as we have a sufficiently fluid understanding that what is "required" is a set of decisions that could generally use some design judgment being brought to bear. I realize full well there are situations where the containing system has a lot of design power, as it were. (Where our system has to fit in to expectations and interfaces that are already pretty well cemented.) But those systems and the situations they drive are going to be disrupted at some point, and it is strategic to take that into account. Too. This extraordinary moment. So many considerations. Judgement factors.
Of course, this isn't the first time I've traced in this space of ideas. But my thinking evolves, as I iterate on it. :-)
1/28/14: I've told you before, Randall totally works for me. No really -- words.
More about words:
1/30/14: Why don't more things go wrong?
Sigh... We need to do all we can to stay gentle with each other... Life just hurts sometimes and we might do something out of alignment with our best self and cause hurt... So much goodwill, good intentions, kindness, and somehow something trips emotions and it gets messy.
On the one hand, it is too bad we know the "dirt" on Richard Feynman's divorce, and on the other, it is reminder that our human condition is well human. This living out loud in public stuff is risky. I know. One part of me is in horror of tracing! And tweeting. And having a presence on the i-way.
1/23/14: It's been a year since I mentioned Jim March's movies on leadership, hasn't it? Must surely be time to:
Why do I mention these movies, in this context? Both have as a theme, debunking the overblown myth of heroic leaders. Is Emma Thompson one of the rare exceptions:
Fragility -- It's All Connected!
Utopia or Oblivion...
Yes, that's a title of a Buckminster Fuller book.
1/30/14: ThoughtWorks Jan2014 Technology Radar (covering dashboarding ops; physical gets more digital upliftment; intelligence is invasive unless principled; ... :-)
If we truly want to develop empathy we might want to start with developing a better understanding of ~50% of this planet's population. This is the year of building awareness of how little we read the work of women. Those who read my Trace have a distinct empathy advantage!!! ;-)
Marc Andreesen began by noticing that a smaller proportion of women (11%) follow him, than men. Then he noticed that he follows much fewer women (<20%) than men. And he asked for suggestions on who to follow.
How biased are we in our reading and following habits? Can we do better, if we just become more aware? I find that more women follow me (back) after I interact with them on Twitter, than men -- even if they favorite or tweet the interaction, do they consider looking at my tweet stream to see if I'm interesting? Do some (men and women) filter me out due to gender filters they don't even perceive they have? (Don't we also filter at the seek step, Tim? Oh wait, Tim doesn't follow me. ;-)
What we read is a matter of very personal taste, but sometimes we have to work on opening our minds a bit, and give something a chance.
Here's Maria Popova with some suggestions:
"I am no longer accepting the things I cannot change. I am changing the things I cannot accept." - Anonymous (via jhagel)
"Everyone wants change, but is reluctant to make a change." #readwomen2014
“Vision without action is a daydream. Action without vision is a nightmare.” – Japanese Proverb
Here are some traces on uncertainty and ambiguity:
You can buy them at KnockKnockStuff!
Jadis strikes again:
The sunrise this morning was spectacular though, with the first slant rays dancing in the ice-strung trees.
1/23/14: Pretty morning -- clear skies with a rainbow around the sun. Not a complete arc, but still astonishing -- I've never seen rainbows without clouds in the sky before! It turned out to be -2 degrees F (that's coooooold), but quite calm so fortunately not the wind chill they forecast..
So, we're barreling towards the 8th birthday of this Trace and you're just waiting for February 3 to say all those nice things about it, right?The Conceptual Architecture page has more hits this month than journalCurrent. I guess that it is recommended reading for some classes on software design/architecture.
2/9/14: Develop Strategic Thinkers Throughout Your Organization, Robert Kabacoff, February 7, 2014
I was reminded that I'd introduced myself at the beginning of my Art of Drawing People In tutorial at SATURN 2010 as follows (except that instead of the second slide, I played the beginning of The Emperor's Club, where those quoted lines (on the slide) are spoken:
More here: The End Depends Upon... the Beginning
I thought about submitting a proposal to SATURN 2014 that would focus on some playful (and useful) and some serious (foot in the door of credibility, but also useful) techniques for conceptual architecture design. But actually, that Art of Drawing People In Tutorial would sure be timely about now. [Oh, you get the double-play in the title right? Drawing people. Yes, that. But also getting people to enter into, to engage.]
Dana was invited to do a keynote at an internal conference and he had such a great topic/focus and he thought of submitting that to SATURN 2014 too. But he was just so busy traveling he didn't make the deadline.
The organizer of the Agile Architecture conference in The Netherlands asked if I'd be interested in presenting, since both my name and Dana's name was given to them by conference attendees last year. The Dutch are awesome! #justsaying ;-)
So, should I? And if so, assume you're going, and tell me what topic you would be most interested in hearing from me on?
For those who have only more recently started to check in on this Trace journey, I draw architects as "box and line drawings" -- you know, sketchy conceptual architecture figures. ;-) I call the character Archman, and he turns SIX in March. Time sure slips through the fingers, doesn't it? Ugh.
Oh. And remember. This Trace turns 8 on February 3. You're going to be suitably effusive, no?
Uh... For a lark, I looked to see if anyone had ever tweeted the video of the Picture It talk, given that it is in this topic space of drawing people in ... and one person had... back in 2009 so I missed that, 'til now:
I suppose it doesn't do Aleks credibility any good to say that is the only compliment that video got (barring a nice compliment from my friend Daniel Stroe who had to be nice, naturally)...?! Well, if... being a really gracious kind human being deserves any standing... then Aleks credibility is untainted by that kindness. And, yes, I would talk differently about the brain in the past year or three than I did then (2009), although the larger point I was making then still holds: we might view ourselves and others as "analytical/left brained" or "intuitive/right brained" but we all use both sides of the brain, and all stand to gain from overcoming the notion that "I don't/can't draw," and recognizing that we can draw well enough to draw people in.
Anyway, it does my self-esteem no end of good to see that someone had, in fact, said something nice about it. It feels really.... daunting... to have a video out there that only one person in its history "liked"... Complete silence feels like criticism, leaving me wondering what terrible things people thought but saved my feelings from seeing...
As golden oldies go, our slides on EA as Business Capabilities Architecture (from 2002) got a replay via Emeric the other day. Woohoo. ;-) [You might notice that my name is first on the slidedeck, and I indeed created it. Such is the culture in our field that Dana is given credit for it... Oh, I am grateful it was mentioned. But for those who are thinking women are just making a lot of noise about a non-issue, they might want to start to pay more attention to all the instances that mount up to waves that just wash out the contribution of women in this field.]
As for that video... that was the first and only time I've presented on camera. I'm not usually nervous like that, but I got terrible stage fright with the thought that not only were some people tweeting out (another first for me), but people in the future -- in the future! -- would be able to see my preso. Silly me. I should have realized no-one would be interested!!!!! ;-) And rightly so. Rightly so.
As left/right brain goes, there is a neat sketch around minute 20+ in Bo Burnham's awesome (but NSFW) "what" standup routine. No sacred cow left untipped in that routine! ;-)
Remind Me To
"Reverse" Conway bounced around a bit this past week... Michael Feathers characterizes the relationship as symbiotic... Interesting that there is debate among the scientific community as to whether symbiosis should refer only to mutualistic relationships, or any persistent relationship between two organisms... ;-) From (the always reliable) wikipedia:
As overlooked work goes, my software visualization zoo got no love and that is a real shame. Guys, guys, isn't that rather an excellent way of characterizing the visualization space. ;-)
2010 that were.
Systems are, in a sense, simply capability bundles -- which are themselves bundles of capabilities, with "big new ideas" being more "sophisticated" or "advanced" or "complex" bundles that change the relationship dynamics. Or (in some ways novel, in some ways analogous or even existing) blends of capabilities applied to new contexts. More simply? They're just a remix, for the most part. Borrowed from other fields or applications, bundled up in new combinations to serve different or emerging needs. With some advances or inventive new capabilities in the mix, but not necessarily.
Another sketch mock-up of my exploring-thinking (from 2012):
Getting closer to the end of the month. So closer to February 3! I'm so excited. Everyone is going to be so nice!
Well, .... I'm sure Peter will be. :-) Peter, you are hands down the most generous person my Trace ever met!
I know. I know. This silly vanity has gone on quite long enough. Fancy pouring this many words into the intertubes. Sullying the attention streams of those kind enough to look in here. Really, I should be more responsible!
from the lyrics of one of Sara's songs
Thanks to Peter for hearing the sound of that trace:
Peter, Gene, Stuart. A few good men. All I do. All they do. And the ball is almost never punted on. It is heart-sickening. It really is. I'm not sure if I can keep rekindling my hoping machine.
1/27/14: Here's a little something:
Simplify: Cut the Clutter
Simplicity: The Next Big Thing, Rosabeth Moss Kanter, February 12, 2009
This includes, among other things, a neat reminder that variation (in product lines) comes at the cost of increasing complexity. There is a tension between better addressing real needs of market niches, and adding superfluous, additional complexity (not just in development-evolution, but integration, supply chains, on and on).
“Just like startups that promote the myth of the genius founder, we reward individuals for collective projects” -- and more and more, we expand our minds with compute assist, and cognitive intelligence benefits from ours:
The power to mashup gets ever greater -- and our feeling that "we did it all," alone deserving credit, with it? The more rich the soup of others' contributions we draw on, the more unique our peculiar idiosyncratic remix has a chance to be. So is it our genius, or the genius in the "soup" that compute assist gives us the power to draw on? Interesting time this. And what a future we glimpse!
Every time I see an increment in Peter Bakker's exploration, discovery, building, I get more tingly with anticipation -- I'm so looking forward to Peter's mapping app. Peeeeeter, when will it be in an app store near me?
I like "subway" styled maps -- to me, they are much more powerful than mind maps, for they allow/support a more complex web of connections and thematic interactions. But they are hard to draw as one's thinking reshapes. So. An app.
Go, Peter go!!
Later: Hmmmmm. Text analysis... Where's he going with that? Antici-pa-tion.
Humility and Confidence; Uncertainty and Intentionality
I had the privilege of seeing the outline for Stuart Boardman's upcoming talk, and am excited by what he figures factors into uncertainty (as it relates to organizations and technology) and how he factors his talk. Uncertainty popped back into mind, seeing Rosabeth Moss Kanter's tweet on humility, given our thread on empathy.
We face much complexity and uncertainty. We need to hold ourselves and each other in a crucible where we see ourselves as highly capable (hence able to be confident) and also fallible (hence humble) -- being compassionate and tender in how we view ourselves, so that we can tolerate where we mess up even as we strive not to, even as we aspire to do much good in this world full of surprises and daunting complexes of uncertainty under interactions of so many forces and transpirations of anticipated and unanticipated, even unanticipatable, events,... And. Again and again I return to "how to use conscious purpose without wrecking everything" (John Gall) -- including our own sense of ourselves and others.
[Note: Long complex entangled sentences emulating the reality it is describing. :)]
Image source: Kazuki Yamamoto
As we hurtle towards eight years of architects architecting architecture Traces, I'm going to allow myself the luxury of revisiting some of the kind words people have said over the years. It is a nice excuse to go back and see that here or there a trace rang enough of a bell for someone, that they were kind enough to share a link to it.
Don't worry, there haven't been that many shoutouts, and I'll pick just 1 a day for the 5 days leading up to the 8th anniversary of tracing here.
Thank you to all who have said kind things about my Trace:
Oh, oh, oh:
As amazing traces in the sand go, here are some of the most amazing!
Image right: xkcd 605
Connecting, Extrapolating... Assertions, Projections
The noEstimates wave is swelling...
Reaction to misconception...? Estimates are simply, well, you know, estimates. It is helpful if we can attach confidence levels, but so often our confidence levels are as iffy as our estimates. So why bother with estimates? Because we have to make investment and prioritization choices on the one hand -- sorry, we can't do it all, so how do we decide what to do, and what to not do? And, on the other, we have dependencies and we are trying to raise awareness around what those dependencies are, how they interact, and what to expect -- even as we actively reshape what we expect. So we can have contingencies in the wings. Buffers. Estimates are "stakes in the ground" so we can see the lay of things, so we can sense and probe where the unexpected is rearing its unsettling head so we can move the stakes and design for and around. Estimates are simply tools in the "how to use conscious purpose" game. They help us learn. We figure out as best we can, and then we sense and probe. We assess, orient and adapt. To surface and illuminate issues. To respond. To better understand. To become more wise. More wise, because there is uncertainty and it takes insight and foresight to shape systems -- including the social systems creating systems -- to enable more the outcomes we want.
When we treat estimates as fixed commitments and associate penalties with breach of commitment, we risk driving the visibility truck off the (no)project cliff. Huh? If we make it risky to make how we're doing visible, we're going to promote disguising and obscuring and hiding anything that helps surface and see how we're doing.
Of course, among the "truck drivers" to be implicated here are those who do this: “Studies show that 94 percent of major government IT projects between 2003 and 2012 came in over budget, behind schedule, or failed completely." (Eshoo and Connolly). Do what? Call it failure when estimates are used for budgets and schedules, treating system development efforts more like assembly lines than development of strategically important systems that have crucial arenas of novelty and discovery and inventiveness. We estimate, because we don't know. Estimate -- you know, roughly, approximately, judge what we anticipate the cost and schedule to be. Under great uncertainty -- very roughly! But we do so to see how we are tacking, so we can estimate and re-estimate expectations for all the flows of activities we're bringing together -- not just different pieces of the system like infrastructure or hardware, and software or firmware, or whatever, but also so others in the value stream can be doing their parts.
Pssst, I have been saying for years (<sigh>, <impish wink>):
6/16/14: It is useful to revisit practices we may take for granted and question whether, when, to what extent they (still) apply. The noEstimates discussion serves to (re)surface or take another look at the considerations, concerns, assumptions and presumptions around estimates. It all adds perspective (or to the ability to shift perspective). And, you know, "perspective is worth 80 IQ points" [Alan Kay]. :-) Noticing how our industry does relative to estimates, we could toss the estimates baby. We could decide we're not going to try to look beyond now; simply follow the unfolding of a system, giving the team resources as needed and as we're able to provide them. Where the team and the business are paired at the hip and unfolding together, that makes sense. The dependencies are highly visible, the effects of choices are more direct. For teams that fit within broad webs of interdependencies from threads and flows of value that come together various ways (for new products, there's manufacturing setup, supply chain preparation, channel readiness, partners that need to stay in sync, hw/fw/sw teams, etc.), it helps to have open communication, including a sense -- that is updated and adapted as more is learned -- when and how others can play their roles. If we think that small focused teams are good, we need ways to connect them that are also adaptive. Our bodies aren't simply reactive. We use anticipation -- each step we take has very local anticipation that adjusts how we take the step, but also heads in a direction we have anticipated we want or need to go in. Again, if something unanticipated is in our path, we adjust. We have these many levels of anticipation and adjustment, all the way up to budgeting for our kids' education, saving for college. We know that we have this balancing between anticipation and sensing and adjusting and anticipation. Yeah, Stafford Beer VSM and Boyd's OODA comes to mind. The ongoing process of observe and orient, decide and act and observe and orient. (aside: The "control" language is misleading; organic, dynamic responsiveness is so central to VSM.)
Context factors. And, sure, we have to decide what, in the context, factors most heavily. Situations differ. Demands, drivers, forces, people, ... individual proclivities, ... factor. It is good to revisit our assumptions, presumptions, ask what has changed in our option set, and take a fresh look at how we do things. And it is not good to act like people who make different choices are doing so because they don't get it... They may just get more about their own situation than outsiders are acknowledging.
Image source: internets
The context? So nice of you to ask:
All kinds of delicious, isn't it?
There's logic. And there's logic. It's good if you see what I mean. I think?
Pssst. I had to read back down through RuffyanMe tweets to find that innovative logic one. Why hasn't anyone said anything nice about her? She's quite a sparkly little creation, is she not? Personas have egos too, you know.
Same may be said of tech/engineering fashions, no?
Homework assignment: Relate that to architectural principles. Reports due on Monday morning. ;-)
I hope that I don't seem too pathetic retweeting compliments about my Trace from a year or three ago.... I know that I choose to write in a format that is... idiosyncratic and not everyone's cup of tea. I also know that I make it hard for people to recommend, because it is a very unique sort of thing -- bigger chunks than a tweet stream, and generally smaller chunks than a blog or zine. Evolving material. Iterating over topics that I'm exploring/working on. None of the blog features that enable interaction. So many ways it bucks every recommendation in the "book" of proper form for making it big/popular. I reveal my thinking with tremendous openness and vulnerability, knowing that it is well hidden behind the tl;dr veil of words. It makes this a highly personal space. So reactions to it would be as strong as reactions to me. And the general reaction to me is... no reaction. Still waters run deep and all that, and these are not the depths many can tolerate encountering at all, let alone much.
Why then, do I (playfully) draw attention to whether people do or don't say anything nice? Well, because I don't want a large audience, I rely on a very small audience to give me the positive feedback I get. We all need some positive feedback and inclusion that makes us feel seen, valued, present to the world in this our one short life on spaceship Earth. :-) Camaraderie is important, and I'm going to remind people to give me some every now and then, otherwise it is a lonely thing to be a me. I don't need much. But somehow people seem to forget to actually say nice things to women -- or this woman anyway -- and while resilient as the rest of humanity, we also need some encouragement and positive response to our work and contribution once in a while.... :-)
But I am a happy resilient sort of creature. So even while there is a voice in me that is capable of this perspective:
I do that more because I see how indifference hurts others, even more than it hurts me. I use myself as an example, but my hope is that we become more tender and take better care of others we're in contact with. I have the advantage of being articulate and though shy, I do manage to jump up and down pointing to myself when I need the help of a kind word (a virtual hug, if you like), and I have friends who notice me doing that and pitch in with the kindness of taking me seriously. And besides:
We need to use our words to build. In many ways. Including by providing reflections of the positive. The world gives out negative feedback freely and in heaping-generous portions. Recognition, appreciation, celebration, acknowledgment must be expressed to be known, to provide enriching reflection of that other person's best self.
I have some of the most beautiful friends in the world -- you don't have to know who they are to know that they are amazing for they noticed me and were kind to me -- to me!!! So I am, and feel myself to be, incredibly fortunate! But I also take the liberty of reminding them that sometimes I need all the negatives I perceive and feel to be counter-balanced with some outright positive celebration of what I do and contribute. :-) And the birthday of my Trace provides an opportunity to do that. Through the first five or so years of tracing, it was up to Dana and Daniel to say something encouragingly celebratory, but my Trace has made a few more friends so that part of me has a few more sources to draw on. Some of my friends and most clients don't read my Trace. And of those that do, some are just not comfortable being effusive. I understand. It's not designed for easy consumption. And not everyone thinks that positive responses do good in the world. Personal tastes, discretions, and more, factor.) So. February 3. No excuses. Exceptions excepted. ;-)
And... If no-one else remembers or overcomes inertia or shyness enough to say something nice, at least the birthday of my Trace gives me the excuse to be self-indulgent. Oh, I'm frequently self-indulgent, but most of the time I have no excuse. ;-)
Which reminds me that the other day, scanning for insights on play, I came across/was struck by this (on the theatrical kind of play):
I also write at:
- Bredemeyer Resources for Architects
Architects and Architecture
- Todd Hoff (highly recommended)
- Anna Liu
- JD Meier
Architect Professional Organizations
Agile and Lean
Agile and Testing
Other Software Thought Leaders
- CapGeminini's CTOblog
CTOs and CIOs
CEOs (Web 2.0)
- Don MacAskill (SmugMug)
- Wired's monkey_bites
Social Networking/Web 2.0+ Watch
- Dan Roam
- David Sibbet (The Grove)
Strategy, BI and Competitive Intelligence
- Freakonomics blog
Um... and these
- CNN Money Business of Green videos