A Trace in the Sand
by Ruth Malan
What's a Trace?
My Trace is a playground for developing ideas, for exploring architecture and the role of architects. It is a journal of discovery, and traces my active reflection. I've been journaling "out loud" here for over eight years. To get a sense of the span, calibre and contribution of this body of work, there's a selection of traces linked here. When reading a trace in isolation, it may feel like you've been dropped into a thought fray unprepared for the action that is already in progress. It's okay. You're smart, and my Trace assumes that. You'll get your bearing quickly. Just give it a chance.
Reprise? Well, this sounds like another swing around our block, doesn't it? But, if it doesn't sound familiar to you, it is high time you read The Art of Change: Fractal and Emergent. :-) Oh, Urquhart's post does take its own unique cut through the terrain and is well worth reading. But the ideas have been in play for a while, so there is other work worth tuning in on.
As ecosystems and ecology go, here are some traces:
More on the evolving identity of enterprise architects:
Of course, this trace is a tour de force:
As is this:
And there is this (via Sally Bean):
Fields, or disciplines, like people, need to keep learning, evolving, adapting.
8/4/14: Move over enterprise architects, Watson is here:
8/8/14: Tour de force? Tongue in cheek. Sheesh! :-)
Wow, a client just sent me the participant list for the Software Architecture Workshop I'll be doing with them in late September -- two months out, and not only is the workshop full, but I can begin shaping... Mwhahaha... I mean... That's a wonderful degree of anticipation!
Dana Bredemeyer will be teaching our 4-day Software Architecture Workshop at the Embedded Systems Institute in The Netherlands on December 16-19. Enroll soon to ensure a spot in the workshop -- remember, Dana is awesome. I'm biased, but he is fully booked by existing clients through the end of the year (and into next year), so people who have worked with him think so too.
I've been asked about dates for an open enrollment workshop in the US. The only week I have available this year, is the week of December 8. So, what's the level of interest in a Software Architecture or a Role of the Architect Workshop that week? In Chicago?
This, from an earlier trace, might be useful:
Meetings don't get much love...
My imp wants to interject with something along the lines of that being a responsibility plate we need to step up to...
Your inner Conway is doing gleeful somersaults at that? :-) We work with forces -- compression, tension, gravity -- to design and construct viable structures. Conway's Law is like that -- something we have to balance and counterbalance, to resolve, to create ambitious systems.
Meetings are a mechanism we can use effectively or ineffectively. Relationships are conduits for understanding and influence, and informal and formal meetings are convening places. We need to take more responsibility for the effectiveness not just of our relationships, but the time we put into developing them, and what flows through them.
Alignment and shared understanding of context and priorities and what we're going to do and such, takes getting heads together somehow, somewhen. Call them working sessions if you prefer, but sometimes minds need to sync up, move understandings across the chasms between our craniums, and create new understandings out of the interaction between minds and in the wonderful generative space that opens when minds ignite and spark off one another. It is a privilege to try to convey something, because in that very act, we discover what we think! Getting it out there, in words and images, is important to moving understanding -- our own, and others. The big things we tackle, can't (generally) be done by one person alone; we need some common ground, some shared understanding of context, its forces and constraints and opportunities... shaping perception of "reality" and how we are going to interact with and intervene within that reality to create something together.
I suppose, in a sense, politics is about power and influence, shaping resource flows. It can work through informal, or formal, by soft influence or hard, command and control, authoritarian influence.
There is a bit of an us vs them thing between strategy and execution, talk and action, theory and practice...
Which recalls to mind:
So what is strategy? Here is Dana Bredemeyer's answer:
Dana strongly advocates against pitting strategy and execution against one another in that "execution is more important than" kind of way. For those who insist on drawing out the distinction, Dana adds:
I love the elegant way Herbert Simon evades the word police:
(from Herbert Simon's The Architecture of Complexity)
Eberhardt Rechtin was similarly skillful:
Which gets us back to Alice:
Goodwill, and a willingness to be playful.
[Confession... I used Random on xkcd to generate those links. ;-). A willingness to play... Testing. Testing. ;-) ]
[For meaning to be made, it helps a lot if we enter with a willingness to understand. We can become co-conspirators in the making, or we can be obstinate and obtuse... ;-) Of course,... life, having a sense of humor, ... immediately threw me a challenge...]
Twitter dropped this kraken right into my lap:
Oh, to be clear -- the kraken is the beast of my own understanding, and I'm wrestling with multiple of its arms which are squirmy and I can't pin them down firmly and grasp it all...
I do like the notion of laying out the landscape of the feedback space...
(Hey, multivariate analysis is like water to my inner hounddogue ;-) Many fun. Such... Oh. )
The easiest dimension in Kent's feedback landscape for me to understand is frequency -- on what timescale do we want to consider feedback? If, for example, we want feedback every minute, we will only make at most a minute's worth of progress before we get some form of feedback. If getting that feedback involves some setup time, that enters our tradeoff landscape. How much we can get done per unit of time, enters consideration too -- if we are looking for feedback on work chunks that take on the order of a few minutes, the amount of work (or chunk size -- or scope?) we're getting feedback on is quite different than a day or week. That has implications for how much backtracking we might have to do, given the feedback. So frequency is interacting with setup time and the cost of being wrong -- failing the test, discovering where we went off course, and how much has to be reworked in the process of setting it to rights.
The scale Kent uses on the "scope" dimension threw me. The way I make sense of it (being labelled with scope) is -- the more code matter (or the broader the scope or amount of programming work we're getting feedback on -- lines of code, a class or other unit, a feature, a system, system in various use contexts) we have in hand, the further we can get down the axis Kent labelled "scope." [That's just my jaunty interpolation; I'm anticipating being set straight on how to read that scope scale and section! ;-)]
At those different points along the axis, the viable sources of feedback shift, as does what we can get feedback on. It is likely not viable to get market feedback in the form of dollar spend if all we have is merely a few lines of code (or a small increment of lines of code), but we can see if the parser snags or the compiler barfs.
So scope (simplified to chunk [which may be a chunk-of-chunks] size we're getting feedback on) and frequency -- lag time? -- interact with the source and nature of feedback.
As sources go, we can look to compute (giving feedback on the code: parser, compiler, ...; giving feedback on execution: logs and other mechanisms to sense and monitor operational data, etc.) and to our audience/stakeholders --
We can't get feedback on value from the compiler. We can't typically get feedback on scalability from the user, at least when the user is wearing their "user" hat. Etc. The user, usually, is not going to be able to give feedback on code qualities like understandability and modifiability. And while they could catch things we just did wrong, we want to catch errors in our logic/thinking before they are deployed to users.
So we need to ask ourselves: What is the nature of this decision I want feedback on? What is impacted? Who cares? What do they care about? How can I tell if I'm on track? When and how can we get feedback that illuminates whether and where we need to make course-corrections?
If we want earlier feedback, we need to ask what kind of feedback is viable, on what timescales, and how useful is it. Can we construct proxies, or indicators, so we can get earlier feedback, and can we create useful rollback points, so our building blocks can be swapped out and replaced more readily?
Unit tests test whether a code chunk meets the expectations/commitments we have for that chunk (built right), not whether those expectations are useful/valuable (right system). But our expectations are constructed as intermediate standins for a larger chunk of value that we can get different modalities of feedback on, from different feedback sources. And we want to get those other forms of feedback as early as possible, too, so that our cost of being wrong is kept manageable.
Which I suppose flips the consideration space. What can we be wrong about, and how quickly can we catch and correct mistakes, misperceptions and missed directions? And how does that interact with setup time/cost? And what scaffolding do we need, so we can rollback and correct?
And so forth and so forth... ;-)
Why am I interested? Have you read Getting Past ‘But’?? ;-)
Or seen this:
Yes, we bring testing (that is, seeking feedback) forward. The feedback landscape is quite germane.
Of course, it is messy...
Um. Messier still...
Well. Probably more messy than that, but you get the idea. Goodwill, a willingness to be playful, and a sense of humor.
Remind me to remind you about good, right and successful, and right system built right, and the feedback landscape, okay?
[The clarity dimension? You tell me. My sensors sniff red herring, but that only means there is something more there for Kent to teach me, if only in the form of me being nudged to discover what I think. Which is the best sort of learning, and gets us back to Kent's tweet. The phrasing of which threw me, because it is a trojan horse or head fake sort of thing. ;-) Let me remind you -- I know. ]
[The more narrowly scoped what we are evaluating is, the more finely we can target it, so the objectives or desired outcomes we are assessing against can be stated more concretely. And in that sense, we can resolve our assessment criteria so we get binary red/green fail/pass feedback. Widen the scope, and more comes into play. More interactions, more tradeoffs, more shift into qualitative judgment calls. Etc. ]
8/19/14: A while back (May) I focused on TDD as one of the tools in our design thinking toolkit. Here we focused on the feedback landscape, and locating TDD within that landscape. Back in May, I collected together links to several posts on TDD, especially related to "why TDD" and TDD and design. Here's another, with a different slant:
Puts a little spin on that "face with a view" [now I have to add another set of brackets to self-(d)e(f)facing!!] in the context of self-promoting my Trace. ;-) Especially when I'm the only one who enjoys it? Ewwww. ;-)
[Ummm... I came of age with the incongruities of South Africa and Monty Python/Fawlty Towers playing in the background. Not 'scuzing nothing, just 'splainin. Dana asked what that dog picture (on the kraken post) was about... I showed him what my face does after I've gone diving into a pool chasing the stick of my own understanding... Yep, my jowls... I showed him literally what I meant figuratively. These things are not pretty. I grant.]
and was reminded of Michael Feathers' keynote at Ruby Midwest last year, where he makes the case for "Deliberate Reflective Design" (a call to use judgment rather than uniform application of standards and principles).
Like... Who knew?
Context, and all that?
I do like Alistair's post -- much that is super-good/useful in it, like the "value center" notion and the importance of mood and trust.
Teams have been tackling the issues of complex systems and their implications for complexity in the organizational structures and relationships all this time, and there was a lot of stonewalling when it came to organizational complexity and system (of complex system) rooted complectification. ;-)
We have learned a lot from all over this industry. We have much more to learn. And it seems like we can learn a lot if we acknowledge that some frontiers have been pushed while others were paying attention elsewhere. Models got shoved under the rug in some places, but reshaped and repurposed in others. BDUF got fed into an iterables pipeline, or something, and is now a whole different flow-and-transformation dynamical structure. ;-)
We can treat each day in the software world as an entirely new day, full of fresh-born unprecedented insights. Or, we can understand that we have a lot worth building on. Okay, we also have to toss some stuff. I'm just saying that the 'tude may be what needs to go into the wash first?
We put Curiosity on Mars, people. Sometimes we do hella complex things. Sure. We fail. Sometimes it's whale of a fail. But still. We do big things, too. Like your car? Sure, it's glitchy, no doubt. But... Lots of software in those things. We notice the fails -- they bug us, even maybe endanger us -- but it can be easy to overlook how much we have come to depend on complex software woven through our lives.
I've been enjoying Kevlin Henney's slidesets -- in good part because Kevlin does a really nice job of drawing upon classics by the pioneering luminaries of our field. as well as more contemporary work, like blogs. It makes Kevlin's work stronger to explicitly do that "I'm standing on the shoulders and ashes of giants" (Booch) thing. Gene Hughson likewise does a lovely job in his blog of drawing on other perspectives and work.
8/17/14: Yesterday I watched:
It was neat to get the words Kevlin puts to those slides, and see/hear him in action -- engaging and insightful.
Because we position principles in the architecture space, I have had to wrestle with the term too; this is how I put it:
A design principle is one that helps us to attain sought design outcomes.
Blogs and microblogging like Twitter, videoblogging and Youtube, along with Instagram and more, brought radical disintermediation to publication and other media. But publishers also served to vet quality and get word out. They set a bar, so reputation and trust came along with the name in print. As we move ever more to disintermediated media, we take on the mantle of getting word out about work we want to encourage and support. If we see this as an attention sharing economy, will we do more to direct some of the attention we so readily give to the "1%-ers" to others who are deserving of sharing some of the attention capital?
This is the time of our lives -- let's make it great for each other. Notice, appreciate, celebrate, connect. Too late always comes too soon.
8/13/14: Mutualism... simulation of ecosystems, not social networks... but interesting:
This, from a trace in 2009:
That struck me, because... yesterday Sara read the xkcd banner caveat out loud to the kitchen gathering:
and I thought my Trace should come with a banner warning: this Trace contains RECURSIVE HUMOR (WHICH MAY BE UNSUITABLE FOR SOFTWARE DEVELOPERS).
Tee hee. Uh oh. I see pitch forks. ;-) [Recursive and humor are all very well, but put them together? And point them at me? Not a good idea!!! Except that No-one reads here. Phew. :-)]
No comment facility on this Trace? Makes sense, considering...
Recursion? Oh look what my brain found in the tweet stream (thanks to Pablo)::
Okay. That's it. I'm outta here. ;-)
I've offered the following for discussion in workshops from time to time:
What do I mean? Well, for example an engine "converts energy into useful mechanical motion." A carburetor "is a device that blends air and fuel for an internal combustion engine." Each has a single cohesive "responsibility" (or defining purpose?), but the responsibility of the engine is at a different level of abstraction from that of the carburetor. Sure, the "engine" abstraction has sub-responsibilities that align to produce its primary responsibility. The conjecture is that it is useful to design abstractions with the (guiding) principle: a single responsibility at the level of abstraction of the abstraction (or element or concept or part, etc.); alternately put, don't have a mix of responsibilities that cloud the defining purpose of the abstraction. That is, separate abstractions along the lines of cohesion of concerns.
Of course, judgment factors. And factors and refactors. Which is to say, as we consider responsibilities and various alternative factorings, we may redefine the defining purpose (or generalized overarching, unifying responsibility) of the abstraction under consideration. And so it goes.
You know. Messy.
7/18/14: More? Oh all right:
<Er(r)... um... Ruff -- Why did you put a link to tautology on "means"?>
Well, you see. It's the point, isn't it? What? Playing with the circularity. The iterative nature of it. Judgment factors, as in judgment is "something that helps produce or influence a result." Using judgment, we factor and refactor. As in, we cluster responsibilities and see how that does against our sense of design integrity, desired/required qualities, etc. And then maybe we try another factoring. And. We factor in, we factor out -- we weigh concerns, determine what is irrelevant, what is "tantalizingly almost relevant" (Bucky Fuller), and what is central.
A useful principle guiding our design thinking as we factor responsibilities and craft abstractions, is to seek cohesion within our abstractions, which may be expressed as alignment of responsibilities around a defining purpose, or an overarching, unifyng responsibility. Which produces good things. Modularity being one. Yep. CRC baby. At the level of abstraction of the abstractions we're designing.
Design is not a set of equations, but we are making tradeoffs and judgment calls, resolving competing tensions. So we need to do that deliberate reflection thing. And apply heuristics and guidance drawn from past experience -- do that "standing on the shoulders and ashes" thing. [And ashes? That was Grady Booch's term (I don't know if it was his invention, or if he was standing on shoulders there himself), and I like it -- we build on what we learn from failures, not just successes. As well as those who have gone before, so ashes in that sense too.]
And yes. That's just SRP. And CRC. Nothing new here. But you see, there is. There is the Master Butcher. In a workshop recently, an architect protested that he did that stuff in the 90's. True. And not. There's hacking the system-beast and dulling the figurative knife with each metaphorical ox that's slaughtered, and there's finding the natural structure of the system. Therein lies mastery. A willingness to find the natural divides, and when it gets tricky, to slow down and go carefully.
Aside: Of course, the knock-down argument applies to the engine example -- for example, the engine provides heat to the heating system. Nonetheless, the focus of the design of the engine is on its primary purpose or overarching responsibility.
8/19/14: See also:
Actually.... the idea of 'modeling the world' was only an approximation anyway. We mix various analogies from the "real world" into our code concepts. Some come from the domain, some from elsewhere. Our mechanisms for system-serving capabilities, for example, often cut across business domains, and have names that bring information/ideas from other domains into ours -- think fork and bridge and port and so forth, ad infinitum. [System-serving capabilities? Like logging, persistence, prioritizing and resource allocation, and so on, and on. Of course, mechanisms are generally cohorts of components collaborating, and the analogy may have more notional leverage than structural.]
I've suggested, jokingly, that analogy-oriented programming should be a thing. :-) But there is something serious under the jesting, which is the tip to look for analogies not just in the business domain being served, but in biological, mechanical and social systems too. Not everyone dances with analogies quite as readily... So. Caveats apply.
But. History is old. What are the interesting forward-looking ideas we are being tantalized to rout out? Services know how to take care of their own business, so to speak.
The tl;dr version of this trace:
Anyone who thinks this is a meritocracy is forgetting that merit in a glut of merit needs something more...
Advocacy is also personal -- those who generously and insightfully point out and show others important ground breaking work are crucial too. If not for them, the work goes unnoticed and unappreciated.
"extraordinary act of intellectual generosity"
Alas, no. But. One day? ;-)
I know. I know. Lots of fails, but hey, that's how we learns, right? Posit, explore, test. Sounds posit-ively...
Ordered yesterday. Arrives Monday. This one I need on paper -- I expect to scribble all over it, and I like to do that on paper. It's how my mind leaves the trace of its melding. ;-)
Yes, that is meant to produce Say You, Say Me echoes. And, in turn, Echoes. :-)
I've been enjoying Peter Bakker's photo stream -- seeing what Peter notices and captures. There's the physical world, and there's what an interpretive artistic mind sees and expresses, shaping what is presented for us to see (into). It strikes me, too, when Dana and I both take photos, what he notices that I never even saw, until I'm looking through his photos. Likewise, when we've been in the same meeting and share notes afterwards. He'll be like "what, he said that?" and vice versa. Not only are we different, but paying attention to some things means not noticing others. So when we put our notes and noticing together, a rich picture forms.
Why you no retweet:
I mean... if that doesn't get retweeted, then there is no hope at all for me...
No wonder I don't get retweeted.... (a few exceptional exceptions excepted)...
It's Feathers Day Y'all!!
Need the backstory?
Here you go:
So. That means he's made it to the over side of the hill, right? Oh, you know, the warranty on all the parts expires, but the value just keeps going up on vintage models like him.
We should roast and toast him, right? We all know his technical work, and appreciate the contribution he has made to our field.
And we have this sense that... he is... unique...
In a twitter-topping way!
And that's just a smattering of mfeathers from July. Your mileage may vary, but mfeathers has a way of busting up hard-packed assumption ground, so new insights can flourish... Or... he whips the dust covers off our mental furniture, confronting us with our preconceptions... Or something... :-)
Michael's aphorisms work, often, by unsettling, surprising, rejiggering, more than by darkness (there might be some; life, you know), but since aphorisms are topic du jour today, this (via Richard West via Ivo Velitchkov) struck me:
Well, life is full of shadow and light, so what Michael deftly plays into sight, may be dark. Or not. It's more about insight, but with distinctive playfulness.
I also write at:
- Bredemeyer Resources for Architects