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.
Enterprise Architect -- Reprise?
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:
- Is Enterprise Architecture Completely Broken?, Forbes, Jason Bloomberg, 7/1/2014
- Can Enterprise Architecture Reinvent Itself for the Agile Movement? by Huw Morgan, July 11, 2014
- Re-Thinking Enterprise Architecture Using Systems and Complexity Approaches, Sally, Bean, JEA, 2010
- drEAmtime, Ivo Velitchkov
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:
A Room Where Executives Go to Get Help from IBM’s Watson Researchers at IBM are testing a version of Watson designed to listen and contribute to business meetings. By Tom Simonite on August 4, 2014
8/8/14: Tour de force? Tongue in cheek. Sheesh! :-)
"But let's drill into the nub of the problem. The reason that so many tools have become unwieldy is that they chase after certain values that add complexity but not usefulness to SMB-sized projects. For example, in the conversation I linked to last time, XML co-developer Tim Bray was struggling with Gradle, a build tool we covered recently in Dr. Dobb's. Bray was complaining of having to read through a 60-chapter document to get what he needed. Hans Dockter, the primary developer of Gradle, responded that the product was designed principally for scalability. This is an important detail. If you're considering Gradle, is scalability the problem you're trying to solve? If not, you might well be giving up simplicity for a capability that will not be used."
-- Getting Back to Coding, Andrew Binstock, July 29, 2014
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 will be facilitating a 1 day workshop on Software Architecture at the Software Architect Conference in London on October 14. Come too -- Richard West will be there, and it's going to be awesome.
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:
The Software Architecture and Role of the Architect Workshops do overlap somewhat – where we do both workshops with the same people, the Role Workshop draws on an additional set of material, but in either case, architects will get the core concepts, guidance and key models for architectural thinking/designing/communicating, and so forth.
That said, the design of the two workshops is different:
- The Software Architecture Workshop follows the Visual Architecting Process (informal)
- The Role of the Architect Workshop follows the Architect Competency Framework
However, a good part of architecting involves the “soft skills” of understanding what is strategically significant (hence what are the demands on the architecture and how are these shaped), and making and communicating decisions. These are technical decisions with business and organizational consequences, that need to be understood and embraced to be delivered on.
Often, clients who have teams of architects of different “flavors” (software, embedded, mechanical and electronic systems, infrastructure, test, domain, portfolio, solution, enterprise, etc., etc.) will go with the Role Workshop rather than the Software Architecture Workshop, for obvious reasons. But the essential skills of system thinking and modeling, strategic thinking (understanding what is shapingly important in the business space, so technical decisions support business intent), leadership, and so forth are going to come up in any of our architecture workshops. It is more a matter of what is primary and what is secondary. In the Software Architecture Workshop, the focus is on creating a draft (set of views of the) software architecture, and discussions of leadership and so forth are secondary, but very, very important. (There is no point to making decisions that are ineffective either in their focus or in organizational follow-through.)
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...
"The quality of your architecture can't be better than the quality of your meetings" -- Dana Bredemeyer
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. Context and judgment factor. It's architecturally significant.
I like this point, and how it is put:
"You just look at the alternatives; analyze the merits vs. the problem at hand, and may the best option win. This works out well if you are the king (or work alone which makes you the king by default) -- otherwise there are other people and they won't necessarily agree with you."
Arnon Rotem-Gal-Oz, Architect Soft Skills, 10/26/08
There is a bit of an us vs them thing between strategy and execution, talk and action, theory and practice...
“In theory, theory and practice are the same. In practice, they are not.” ― Albert Einstein
"In theory there is no difference between theory and practice. In practice there is." -- Yogi Berra
"When you come to a fork in the road, take it" -- Yogi Berra
OH at Universal Studios (via Dana Bredemeyer): "Which way do we go to get somewhere else?"
Which recalls to mind:
"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
`I don't much care where--' said Alice.
`Then it doesn't matter which way you go,' said the Cat.
`--so long as I get somewhere,' Alice added as an explanation.
`Oh, you're sure to do that,' said the Cat, `if you only walk long enough.'
-- Lewis Carroll, Alice's Adventures in Wonderland
Alice looked round her in great surprise. 'Why, I do believe we've been under this tree the whole time! Everything's just as it was!'
'Of course it is,' said the Queen, 'what would you have it?'
'Well, in our country,' said Alice, still panting a little, 'you'd generally get to somewhere else — if you ran very fast for a long time, as we've been doing.'
'A slow sort of country!' said the Queen. 'Now, here, you see, it takes all the running you can do, to keep in the same place.
If you want to get somewhere else, you must run at least twice as fast as that!'
-- Lewis Carroll, Through the Looking Glass
So what is strategy? Here is Dana Bredemeyer's answer:
"Strategy is a process that asks, answers, and co-ordinates the interaction of these questions, and facilitates the evolution of this process over time:
- Who we are (identity, values, ethics, capabilities)
- What are our desired outcomes (mission, vision, objectives, goals and timeframes)
- What is our context, or situation (the world, trends, forces, resources, evolution...)
- What are the essential things we must do in order to realize our desired outcomes?"
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:
"If we divide the world up into strategy and execution, then I want to add a third component. I’ll call it achieving organizational coherence. This is the degree to which there is shared understanding and shared enthusiastic commitment to the desired outcomes and the strategy for achieving them. The ability of every organization, large or small, to do anything, is limited by what they can achieve organizational coherence around, regardless of how exquisite its planning or effective its execution."
I love the elegant way Herbert Simon evades the word police:
(from Herbert Simon's The Architecture of Complexity)
Eberhardt Rechtin was similarly skillful:
"The term 'architecture' is widely understood and used for
what it is--a top-down description of the structure of the
system." -- Eberhardt Rechtin, Systems Architecting: Creating and building complex systems, Prentice-Hall, 1991
Which gets us back to Alice:
Humpty Dumpty smiled contemptuously. 'Of course you don't — till I tell you. I meant "there's a nice knock-down argument for you!"'
'But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'
'The question is,' said Alice, 'whether you can make words mean so many different things.'
'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'
Alice was too much puzzled to say anything; so after a minute Humpty Dumpty began again. 'They've a temper, some of them — particularly verbs: they're the proudest — adjectives you can do anything with, but not verbs — however, I can manage the whole lot of them! Impenetrability! That's what I say!'
'Would you tell me please,' said Alice, 'what that means?'
'Now you talk like a reasonable child,' said Humpty Dumpty, looking very much pleased. 'I meant by "impenetrability" that we've had enough of that subject, and it would be just as well if you'd mention what you mean to do next, as I suppose you don't mean to stop here all the rest of your life.'
'That's a great deal to make one word mean,' Alice said in a thoughtful tone.
'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'
-- Lewis Carroll, Through the Looking Glass
How very far we can go, when we let context and positive intent and positive expectation, inform our interpretation.
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...]
Kraken, Live and Wriggling
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 very much 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. )
Kraken Wrestling, Continued
To be clear, the kraken I'm wrestling here, is the beast of my own (mis)understanding -- trying to get its multivariate dimensions to fit in my conception.
The easiest dimension in Kent's feedback landscape for me to understand is frequency -- on what timescale do we want to consider feedback? There is a tradeoff sub-landscape within frequency. 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 left me questioning whether I got it. 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 --
- developers (state of the code);
- operations (state of the system in operation -- runtime properties like scalability and availability, etc.);
- users (state of the system in use -- capabilities or function and runtime properties users care about);
- others --- customers (businesses of our users); others in the value network; our business (senior management, shareholders, etc.)
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?
The clarity dimension? I'm still working on it, which means there is something more there for Kent to teach me -- also in the form of 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. By which I mean: understanding the feedback landscape well, helps us understand that TDD does matter where it matters. It doesn't tell us things it isn't designed to reveal to us, but it does a valuable job in the part of the feedback landscape it fits.]
This is where I'm at on clarity: 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:
Aside: Why am I interested in the exploring the feedback landscape? Have you read Getting Past ‘But’?? ;-)
Or seen this:
Yes, we bring testing (that is, seeking feedback) forward. If we can do this testing with pretendotypes and sketch prototypes and code prototypes, so we can get feedback on concept and direction, that is part of our feedback toolkit. 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? Cool.
Face with a View
My impish sense of humor really wanted to add the image (snipped from this trace) below, to this exchange:
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.]
To Rules, or Not to Rules
Saw this (via Ivo Velitchkov):
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).
They're Different Beasts!
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:
An Architecture Principle is a normative statement that orients (or loosely steers) and aligns decisions and actions so as to achieve strategic outcomes.
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:
Tonality, and Traces Past
This, from a trace in 2009:
I do tend to (over)use parentheticals, and challenge and stretch the laws of grammatical gravity. Reflecting on that habit, I realized I (try to) use all the powers of (otherwise flat) text to simulate or substitute for tonal variation. This reminded me how important tone is in conversations, and how, working ever more in distributed teams, we have to find ways to bring that kind of vibrancy into written correspondence. Styles differ, of course. One of the chief architects we work with, writes quite brief emails, but each one has a point of original humor so delicious I always read or forward the email to Dana. (For his part, Dana laughs with such infectious enjoyment, one wants to make him laugh!) I don't mean that tonality is simply a matter of gravitas, though it is that. And social dynamics are so important in collaborative work; team "flow" is not just workflow momentum but a matter of fun and openness to influence that generates creative energy. But the artful use of tone also attracts, and shapes and directs, attention. Not that I am artful on that score. But I am enthusiastic. That's not nothing. Right?
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).
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. ;-)
It's Microservices all the Way Down... I Mean, Everywhere You Look
A Conjecture and a Knock-Down Argument... were taking a hike...
I've offered the following for discussion in workshops from time to time:
Conjecture: SRP applies at the level of abstraction of the abstraction. [Further conjecture: this is what cohesion means (in actionable terms).]
Knock-down argument: at larger grains, abstractions may play different roles, and hence have different responsibilities (or responsibility clusters)
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 of the abstraction under consideration, we may refine or even redefine the defining purpose (or generalized overarching, unifying responsibility). We do so prospectively, applying thought experiments, considering for example, impact of conceived changes, but also different ideas about how to achieve desired qualities. And we do this retrospectively, seeing how well we did, as changes come up. 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. What causes the "attraction" that keeps things together in a software element is going to differ, element by element, so we have to consider responsibilities (or function or capability or what this bitty of the system does) and discover the basis for cohesion for each element. So I was just playfully pointing to the iterative nature that is inherent in crafting coherent abstractions. Yes, the refrain: Judgment factors. And factors and refactors. What?? You know. Judgment factors, as in judgment is "something that helps produce or influence a result." And 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:
Merit plus Generosity!
Anyone who thinks this is a meritocracy is forgetting that merit in a glut of merit needs something more...
'Assaf Naor, an Israeli mathematician who has worked closely with Khot for almost a decade, nominated his colleague and friend for a $200,000 Microsoft fellowship in 2005, the National Science Foundation’s prestigious Alan T. Waterman Award in 2010, and this year’s Nevanlinna Prize. “I see in his work more than just a collection of really good papers: I see an agenda, an original point of view,” Naor said. “There are many talented people who can solve problems — few people can change the way we look at things.”'
-- What It Takes to Win the World’s Highest Computer Science Honor, Thomas Lin and Erica Klarreich, 08.14.14
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. ;-)
See You, See Me
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 the sense of deeloping a new form of philosophy-bearing literary art, making it his own.
In a twitter-topping way!
- Truth is danger then fiction, 7/22/14
- Email is the log viewer of your life, 7/22/14
- That moment when everything you know about human nature is true, 7/18/14
- When your mind changes, so does everything else, 7/17/14
- Abstract until there's nothing left and then undo once, 7/1/14
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... :-)
"Just when you think you know something, you have to look at it in another way. Even though it may seem silly or wrong, you must try!" -- Dead Poets Society
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:
"It was in the salons that La Rochefoucauld developed the literary genre for which he has become known: that of the maxim or aphorism, a pithy statement that deftly captures a dark insight into the human soul, reminding us of a wise and often uncomfortable truth. In good hands, an aphorism should deliver its punch in less than three seconds (one might be competing with the arrival of an asparagus tart)."
The Great Philosophers 15: La Rochefoucauld
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. Right? I mean, consider for example: "truth is stranger than fiction" which he turned it into "truth is danger"... and "truth is danger [...] then fiction." I inserted the [...] for a dramatic pause to highlight what happens, when you say truth is danger then fiction. It holds in it all the collapsed meanings that come from our expectations, given the original phrase, along with we do with truth, danger and fiction. It reminds me of Picasso, where elements are abstracted and put into new relationships, that can have no meaning to you, or, out of the interplay between unexpectedness and expectedness, the interaction of new relationships, make you see what you weren't and shake, as it were, new meanings into place for you. It is masterful. Original. Using Twitter as the platform, it is some part performance art, but it deserves to be collected and presented, persisted. Made accessable as a body of work, not just in the transient form of Twitter.
Of course, his tweet stream is so much more than what I touched on here. There is much I could say about the social and technical leadership, commentary and pointers, too.
Roast Toast 'im?
And. We'll have to find out when that secretive shadow-man Pablo has his roast-day, so we can say what an awesome blog he has been building. The latest is masterful! As one has come to expect. :-) I wrestle the kraken of my own (miss(ed))understanding. Paul's images are so much more...
Well, did you get a trace of that scent? Don't try this at home, kids.
As embodied cognition goes, this exposes a literal insight:
"An alternative explanation proposes that gesturing is functional. It helps us retrieve words from our mental lexicon. The speaker says “At the fair we went into a uh…” He falls silent and makes a circular motion with his hand. He then looks relieved and finishes the sentence with “Ferris wheel.” The idea here is that the motoric information that drives our gestures is somehow connected with our word representations in our mental lexicon."
-- Rolf Zwaan, Why do We Make Gestures (Even when No One Can See Them)?
On issues that seem to divide us -- whether it is #noestimates or one of the -isms -- it might help to remember that often people are merely trying to offer a perspective they perceive we lack or may have less access to. We are exposed to different realms of experience, different social forces (much the same, much different). But then, we think they are lacking some perspective we hold, so we offer ours. And they think we didn't get it, so they add emphasis and argument to theirs, and we to ours. That can push us poles apart, unless we recognize it is just the dance of dialectic even though emotions and subliminally cued responses can pull it off kilter as we strive to achieve balance.
Twitter brings so much of the dark side of humanity to our attention, and it's important -- if it weren't for words and images bringing new awareness, how would we reorient and make change possible within ourselves, our organizations, and cultures? But it is also wonderful to lean into great work, and feel the good that people do. See the kindnesses and warmth.
I pushed self-reference to the limits today. I'm so happy that @RiczWest got the (full) recursive joke! Humor pipelining in Twitter? ;-)
When people seldom tweet or retweet pointers to one's work, it really erodes one's confidence, you know? It leaves me feeling that I #fail at this social thing...
But -- gratitude! The exceptions prove exceptional, and I am most fortunate. A few people are very nice to me. To ME! You understand. To me! How unlikely. And yet, necessary.
8/22/14: I had fun seeing how far I could push the self-reference pun with Twitter's limited mechanisms... :-) And it sure was nice of @RiczWest and @schmonz and @Grady_Booch to retweet it (each at a different point along the pipeline).
Repost as a Service
It comes from this Shaping trace, but all March 2013 is worth a drive-by -- it's ...well... awesome, if you ask me. Oh. Right. You didn't. Well, pfft, I never let that stop me.
Yeah, sure, much ambiguity will remain. But the point is to resolve enough to begin to make progress. To get ground under the feet.
Robin Williams Tribute Series
Continuing our tribute series, we watched Patch Adams tonight, spilling tears for all that has happened this past week. Indifference... my, that strikes such a chord...
PATCH: If we're going to fight a disease, let's fight one of the most terrible diseases of all, indifference.
MENDELSON: You are focussing on the problem. If you focus on the problem, you can’t see the solution. Never focus on the problem. Look at me! How many do you see. No, look beyond the fingers. How many do you see? By gazing through at Arthur beyond the fingers hero sees all fingers double.
MENDELSON: Eight, eight. Yes, yes. Eight’s a good answer. Yes. See what no one else sees. See what everyone else chooses not to see out of fear conformity or laziness. See the whole world anew each day.
Value Proposition Design
Prepub tweet-outs from the eagerly anticipated new book by Alex Osterwald:
- "Design is the activity of turning your ideas into value proposition prototypes."
Um... It does take design to do that, but that is not the limit of design!
Can't read the fine print but...
Smiles! I am sure we will get a lot of value from the book and I'm excited. And relieved that he didn't take all the goodies off the table. :-)
Sooooo. We did "judgment factors." What else? From a 2013 trace:
If context is king, diversity is queen. And out of their union, innovation is born
Speaking of diversity... this clearly is a rather something body of work --- buried in our field, no less... Ah. The intrigue. The misdeeds. Buried? In a field?
Diversity? If innovation is very much about novel connections, bringing people with different perspectives together can help. Of course, that gets us back to judgment factors. And context factors.
And, like "judgment factors," it is worth leveraging the inherent double entendre to note -- context factors, as in plays a role. Or should... And context needs to be factored. We need to think about different contexts. Which relates to the fit point in the trace above. There are different kinds of fit -- to purpose and to contexts. Various contexts of use, value network context more broadly -- including value added by others in the value network or ecosystem. There is the immediate context of the containing system-of-systems, and the broader context of the ecosystem. There is the time relationship and context shifts as trends now play out and shape the value landscape.
Oh yeah. And
biases factor. ;-) And innovation is all about factoring new combinations of factors.
As for being buried, in a field... you no doubt missed (sigh) this :
Better left buried, huh?
The slideset? here.
Well, Aaron Patterson is the punniest guy on twitter, so... Aaron was roasted by that Feathers fellow in his Joy of Coding talk (around minute 22). As joy goes, have you heard any of Angela Harms talks? As taking our humanity to work goes, did you see Martin Fowler's "programmers are not just code monkeys" talk?
Use Your Imagination
... to figure out what I could have meant:
I reread this, from a trace dated 1/31/08, and was again amazed:
I (still) don't have time for jotting notes, but I'm too impressed not to make time! You see, Ryan is doing a research project on the Hobie MirageDrive, and he has to have 4 sources—only one of which can be an internet source. One can be an interview, so last week Ryan called Greg Ketterman, Vice President of Design at Hobie and holder of the patent for the Hobie MirageDrive. He didn't reach him, so he left a message saying that he is 9 years old and is doing a research project for school and he'd like to interview Greg and could Greg please call back. Now, I ask you, how many of you would have called back to be interviewed by a 9-year old? Well, yes, most of you, I do acknowledge. But, given an average crowd of inventors and architects? Anyway, Greg called back; that's the part that impressed me. That is what I call amazing time management skills. Something for me to learn from! I mean, an interview with a 9-year old could not have ranked top on Greg's list on any given day. Yet within a week, he managed to call during after-school hours and talked to Ryan for 20 minutes or so.
My, but I've been tracing -- and promising myself I'd quit -- for a long time. ;-)
Cohesion, Crafting Abstractions, and the Matter of Change
My thoughts are still wandering along SRP and resilient abstraction lines...
Cohesion is a slippery beastie... We can go to the usual place, and look for the key under the lamplight wikipedia shines:
Software: "In computer programming, cohesion refers to the degree to which the elements of a module belong together Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is."
And we can widen our search path a bit:
Chemistry: "Cohesion (n. lat. cohaerere "stick or stay together") or cohesive attraction or cohesive force is the action or property of molecules sticking together, being mutually attractive. It is an intrinsic property of a substance that is caused by the shape and structure of its molecules"
Linguistics: "Cohesion is the grammatical and lexical linking within a text or sentence that holds a text together and gives it meaning. It is related to the broader concept of coherence."
And look to reference points in our field. As foundational classics of our field go, here is Tom De Marco's take (lifted from Kevlin's slides, because that was easier than scanning my copy):
Glenn Vanderburg's post is pretty much the go to in terms of contemporary characterizations:
"Cohesion comes from the same root word that "adhesion" comes from. It’s a word about sticking. When something adheres to something else (when it’s adhesive, in other words) it’s a one-sided, external thing: something (like glue) is sticking one thing to another. Things that are cohesive, on the other hand, naturally stick to each other because they are of like kind, or because they fit so well together. Duct tape adheres to things because it’s sticky, not because it necessarily has anything in common with them. But two lumps of clay will cohere when you put them together, and matched, well-machined parts sometimes seem to cohere because the fit is so precise. Adhesion is one thing sticking to another; cohesion is a mutual relationship, with two things sticking together.
This is also why we refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural (it would result in tight coupling!) to pull them apart. Such a class exhibits cohesion. No glue is required, you don’t have to build extra code to make the pieces fit together; the pieces hang together naturally because they’re closely related. In contrast, sometimes a class will seem to have its fingers in way too many parts of your system. Such a class is adhesive, and that’s not what we’re looking for."
-- Glenn Vanderburg, Cohesion, 1/31/2011
But cohesion is still a slippery notion... that is, it is challenging to characterize, once, for all abstractions, under all circumstances, for all time, on what basis cohesion or coherence is achieved in software elements. I have been trying to argue that that is because the basis is a judgment call, resolving goals and tensions that are case specific. But first, lets revisit the proposition that "single responsibility" (or single, shaping purpose, or single capability as seen from the outside) is a reasonable stab at a general criterium or basis for cohesion. If we look at an element's internal responsibilities (as they show up in methods, etc.), and some don't relate strongly to a single responsibility or capability or purpose the element in question presents to other elements, then it's going on our watch list as far as cohesion goes. (Some may be let off the hook if they relate to internal housekeeping, and don't impact the externally presenting capability of the element.)
Uncle Bob (Martin) proposed that an element should have "a single reason to change" and called this the Single Responsibility Principle. So we can look at reason to change as an actionable heuristic to help us delineate class scope/boundaries (what's in, what's out). If we go with that formulation, that would restrict one from generalizing SRP to composite abstractions (and disallow what I was doing in the "conjecture and knock-down argument" trace several days ago). Naturally, I think SRP is too good a name to be limited in that way -- it has gone forth into the world, and it needs to be allowed to grow up to its full potential. :-)
So, I have to ask: Does the interesting question here resolve to: is "change together" the artifact of cohesion (that is, a property of an element that is a consequence of its cohesion) or the (definitive) basis for putting things together? Alternately put, if we put things together because they contribute to a single responsibility (or defining purpose or shaping identity), will they tend to change together? If we run that line of reasoning out a little further: the smaller grained the element, the more focused its function (the more tangible/concrete/specific the concern it is responsible for) -- so the more likely its constituent sub-elements will "have a single reason to change"? So at small grains, do the two heuristics (chunk at "single reason to change" boundaries and chunk around "single responsibility"), point in the same direction?
Further, does (successful) prospective attempts to create cohesive elements, result in retrospectively finding that things that tend to change together were put together? And, as new demands arise, does prospective refactoring to realign with adapting, shifting, reshaping, or even wholely new, responsibilities, likewise later result in retrospectively finding that things that tend to change together were put together? And is the converse the case? If the elements of the system are not (internally) cohesive, do we see this reflected in scattered changes in response to each change event?
I'm not sure if that is useful or not... It just occurs to me that we might look at it backward if we focus on single reason to change when we're crafting an abstraction rather than purpose or raison d'etre and role that it plays in (or contribution it makes to) the system... So "single responsibility" <==> cohesion of subresponsibilities (or "fit" in the "fit together" relatedness sense).
Of course, the "single responsibility" may well be to take care of a difficult design decision (after Parnas), encapsulating it from other parts of the system to shield them from the difficulty (uncertainty, novelty, complexity) of the element (in which case, the element would be at the granularity of abstraction required to take care of that design concern).
And sometimes the defining purpose of an abstraction is "shield from change" -- we see this at boundaries to the system, for example. And...
That said, if we explore possible changes (conducting thought experiments) or investigate actual changes that have been made, that may illuminate alternate factorings that would yield abstractions that are more robust to change (but still have a viable basis for cohesion where subresponsibilities contribute to an overarching, boundary-defining, responsibilitiy).
When driving into a tight garage that is on the left and at right angles to a very narrow dead-end lane, it may be better to back in (when one takes into account that the steering is done on the front wheels). Smiles. What I'm trying to drive at here, is that there are different considerations and forces in play, and change is just one. If we can isolate a well-defined contribution to make in the system, that is a (good?) candidate for chunking (into a class, or other system element). Then its basis for cohesion is the contribution it makes -- its responsibility -- to the system. We try not to let abitrary (sub)responsibilities that have nothing, or little, to do with its overarching responsibility, become entangled within the same element. Clean chunking contributes to changeability, if it helps to find what is impacted, and to localize the impact of change. And to tractability, if it helps as we reason about the system. So we're looking to "right-size" building blocks -- to give cognitive assist (understandability, reasoning, findability, memorability, etc.) as well as for replication and adaptation (of various sorts, reuse, distribution, scaling, robustness, ...), etc. Lines of change is one of the natural "fault lines" or interstices or cell boundaries or... whatever, that we are looking for/at as we decide what to factor together and what to factor out and split apart. But cohesion, alignment, fit around some responsibility to the system, some natural chunk of contribution, some cohesive purpose, is also - or more? -- important as a chunking strategy, Yep. Cognitive tractability is huge.
Not that I give you any reason to think that I value cognitive tractability, given how obtuse my Trace is, huh? Well, you know, judgment calls. I figure that getting my ideas out is one kind of value. Being quirky and distinctive is another. And obfuscating so that hecklers and trolls are confuzzled is another... ;-)
Hm. What does parking in oddly constrained situations have to do with cohesion, and chunking? Cohesion is about what "fits well together" but "fits well together" is a matter of judgment calls. Tricksy, non-obvious judgment calls, often. Refactor much?
Another attempt at corraling this tricksy beast of understanding... may take a tack that goes something like this:
What we are looking for, when we try to craft "crisp and resilient abstractions" (or internally cohesive chunks), is lines where intimate mutuality, co-dependency/interdependency or coupling within the entity is considerably stronger than coupling without. If our cut lines create abstractions that are too fine, we have more inter-element interaction and these are a cognitive burden. We want to chunk our system for various reasons, but reasoning is a big one -- especially when our systems are so complex, we have many people all trying to make sense of and reason about the system, to make sensible adapations and additions to it. If the interactions cross boundaries they incur other overhead (communication, latency, whatnot), but even in the simplest deployment scenarios we still have cognitive load (understandability, findablity, evolvability, etc.) at issue.
But again, cohesion around some overaching responsibility (or commitment/contribution to the system, or role and its purpose within the system) directs attention towards factorings that have a "boundary" within which sub-elements have distinct roles but they contribute to the health and functioning of the element as it delivers its responsibility (to collaborating elements and ultimately) to the system. And that boundary is resilient if there is not so much interaction across the boundary as to make it indistinct. If we choose poorly, or are careless or just misunderstand the basis for cohesion for the element, we can accomodate and compromise the boundary to the point that it, in effect, has dissolved away and elements merge by subsumption of other responsibilities or by erosion of boundary. (You get entanglements and hairballs, rather than crisp coherent abstractions.)
I mentioned this to Dana, and he said something very interesting, as he does. He said "to tell if an element is cohesive, you must look at it in its context." That brings a flood of images to mind, both of physical systems and software, and I like it a lot. I've been talking about boundaries, and interactions, and "see it in its context" calls to mind seeing if it has crisp boundaries or if the interactions and dependencies smudge the boundaries. Do parts of it interact more with outside thingies (a technical term introduced by Grady Booch :-)? But also, and this is a point Dana made, does it "jar" or fit in its context? If it is well-crafted, not only does it have internal cohesion, but while delineated or separable from its context, it fits the context well. So there is something meaty to go after there, around being internally cohesive and loosely coupled to, yet having coherance with, not just within, its context. It is compatible with other elements it collaborates closely with, but it isn't highly intimate with their internal workings. Oh, sure, we call that encapsulation. But the point is, looking at its interaction surface (interface) we can tell a lot about the cohesion of (that is, within) the element.
9/11/14: Jabe Bloom:
Aside: When I say "reason about the system" I assume that is grokkable. But I mean, for example, think through how to do something challenging, identify and think through options, weigh alternative approaches, resolve tensions or make tradeoffs, stay within constraints and address demands, etc.
8/27/14: Why spend so many words on a principle, and the underlying matter of cohesion? Well, I wanted to put a pithy wording to a "scalable" statement of the Single Responsibility Principle: "SRP applies at the level of abstraction of the abstraction." But, it was a slippery slope and those are so much fun. :-) Of course, judgment applies (or factors). Even a design as tested by evolution as our anatomy, has deviations from the principle... Take the mouth and esophagus. Sure, both serve to ingest, but they ingest for different (sub)systems, so they blur the lines on that "do one thing" or "single responsibility" principle. This gives the mouth and nose some redundancy, but choking can be a hazard especially for exploratory toddlers.
But further, we tend to have this focus on change. Yes. It is important. We have to worry about the habitability (as it were) of our code from the perspective of developers who will be living intimately with the consequences of our design decisions for years to come, not just the habitability of the software for users who wrap the software into the flows and structures of their lives.
"This focus on change" -- what do I mean? Well, one of the characterizations of software architecture that has the most gravitas for people is Grady Booch's:
"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch, blog post, March 2, 2006
And we have Bob Martin :
Single Responsibility Principle: "Gather together the things that change for the same reasons. Separate those things that change for different reasons."
I think change is one of the factors in play. Our eye is so implicitly on the ball of delivering capabilities to users, that can stress and so warp the system that we have the system that has earned terms like technical debt (in the entropy sense) and kludge and big ball of mud. The resulting entanglements so mire the system that change is a concern that runs deep with us. As it should. But is change the driving consideration for structuring decisions, or is it how we choose between and sanity check options? Sure, sometimes it is the predominant or driving concern. But often it is among the concerns we're striving to address.
"Gather together the things that change for the same reasons" is a good heuristic -- but because the "same reasons" may give clues to a basis for coherence. The reason may be shielding the system from a source of repetitive or ongoing change, or a source of change that would totally ungird the system if we didn't isolate the changes from that source, so that we can address it locally. But as we shape abstractions, it is one of the heuristics we have in play. A single responsibility, giving the element distinct identity and purpose or contribution to make in the system, is perhaps, the governing or superordinate principle, while "change for the same reasons" or "change together" is strongly complementary, perhaps even the dual.
Maybe. Just thinking out loud here.
In a characterization of architecture, I want to see identification of the strategically and structurally significant demands and challenges of the system and how we are going to address them. What is make or break? What must this system critically do, to be this kind of system? What are the key structures, and their interactions, needed to do that? What is our theory of operation that convinces us that we can meet those demands we deem core and strategic to being this kind of system, meeting these kinds of needs? Oh sure, system elements that are structurally significant will tend to have a high cost of change associated, and high cost of change is strategically significant -- if we make a bad choice, it can cost our very viability. We also characterize architecture in terms of scope, and what decisions need to be made holistically (e.g., from the perspective of the system in its context, or where the impact on system properties needs to be taken into account, and so forth). But that is another slippery slope. If you want to play on it, here you go:
'The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise' - Edsger Dijkstra
pairs well with:
Wrap Your Head Around This!
In case you were wondering:
...so, less is more?
- Bredemeyer Resources for Architects
- Trace In the Sand Blog
- Journal Map
- storylines tubemap by Peter Bakker