me.andering – Willem van den Ende

The unprepared session at agile open prepared us well for the brown bag session Bernard Notarianni hosted subsequently over lunch, to show how they are done in his workplace. These brown bag sessions each deal with a chapter from Quality Software Management (the four volume book series by Gerald Weinberg).

Bernard Notarianni explains the first chapter of Quality Software Management

I’ve participated in many discussions on software quality. Usually, it leads to babble and nothingness… This time was different. Discussion on ‘what is software quality’ was focused, and I learnt a thing or two about it. The format of the meeting is simple. Everyone reads a chapter, there is some discussion on the content, and then the group does one or more exercises – QSM has exercises at the end of each chapter.
They have these meetings every two weeks. At this rate, they’ll be spending the next couple of years working on it. Bernard says it works great for them, and they’ve been doing it for quite a while now – looks like years of fun and learning to look forward to.

European consultants camp is now over. This post was, like the others this week, written beforehand. I’m sure…

‘it was pretty much amazing’ comic by Adam Hally

Because beforehand the sessions requested and suggested, the people attending and the location looked pretty much amazing. Some who couldn’t attend were already looking forwared to next years’ camp…

I’m likely to go really offline for a couple of days. Time for some R&R after intensive days of conferring, drinking and laughing .

Raphael Pierquin requested an unprepared session at Agile Open. I guess many people would feel an unprepared session, even without a formal agenda at the beginning would lead to a conversation like this:

there were two muffins in an oven comic by Adam Hally

People often fear the same of an unconference as a whole. The unprepared session turned out to be exactly the opposite.

The conversation was extremely focused. We used Moo Cow several times during this session. Calling “Moo” helped us to keep laughing, it was a great paradoxical way to maintain focus. Everyone was listening intently, all participants were facilitating the discussion, and we got time to work on some topics in depth. Raphael started off with a difficult question that we delved into, after that we tried a temperature reading because several participants wanted to try it out.

After the temperature reading, we had a discussion on the forces that make it work or not. Because the unprepared session took place in an unconference, participants could (and did) walk in and out of the session at any time. Several people joined in halfway through the temperature reading, after we had done the appreciations. Again it turns out appreciations have a special effect on the meeting. If you join a temperature reading after the appreciations, you miss the atmosphere, and the other participants can not bring you ‘up to speed’, because the atmosphere can not be verbalized.

Neither can the unprepared session. I hope I gave an impression that does it a little justice. I hope to have some more unprepared sessions here at european consultants camp.

I mentioned the “Moo Cow” in these are just some of my favourite tools as something that people looking at the output of that session found most puzzling. Then I go on not explaining it…

‘cow’ by Adam Hally

Which provides a perfect hook to explain how “Moo Cow” works in a meeting.

Emmanuel Gaillot reported it as a favourite tool. The context in which it applies is a meeting where someone is confused by what is said, or disagrees but doesn’t know how to put it in words yet.

The original application of “Moo Cow” requires a toy cow. If you tip the toy cow, it says “Moo”. Upon hearing the “Moo” the meeting participants will probably start to laugh, and break out of whatever they were doing, which is exactly the intention.

After the “Shu” phase with the toy cow, people reportedly started sending e-mails with a “Moo” audio file attached.

It also works, when you just say “Moo”. Especially if you haven’t introduced the “Moo Cow” technique formally before . I’ve used it at Agile Open, where it was very useful during the unprepared session.

Counter indications for use: Do not apply “Moo Cow” in contexts where seriousness reigns supreme. There has to be room for relevant irrelevance (aka unserious seriousness).

(I’ve also heard of the practice of cow-tipping with real cows, I’ll leave that till another time, in case anyone is interested…)

I wanted Agile Open 2006 to have an atmosphere like Cheers:

‘I wanna be where everybody knows my name’ comic by Adam Hally

and it did. As I didn’t tell you yesterday (Change club), I’m now at european consultants camp. Can’t tell you what is going on there right now, as we probably don’t have an internet connection. Not having an internet connection at a conference gives it a much higher level of “off-siteness”, getting people to talk to each other, rather than talk back home, or drift off the internet. Some people bring their families, so they don’t even have to call back.

I put up a mailing list for this year’s participants, two weeks before the start of the conference. That works great as a way to (re)know our names. We had a thread of “requests for sessions”, where participants request a topic they would like to explore, and others respond with what they have to offer.

I wanted to have a “parts party” because I heard about it, but don’t know exactly what it is. Nynke Fokma, Bent Adersen and Marco Riccioni offered to host one. They discussed some of the parameters and properties of it on the list, so other participants know what to expect, and already have something to refer back to in case they’d later like to run one of their own.

The comic in this post comes from the series “Happy Go Lucky” by Repoort.

I’m driving down to a small seaside town in France to participate in an open space unconference for consultants but I can’t tell you about it…

‘Fight club’ comic by Adam Hally

Johannes Link wrote What’s an architect anyway?
in response to Customer Oriented Architecture.

We seem to find ourselves in a similar spot:

“Now – for our customer’s sake – I’m sometimes called an architect myself”

Johannes agrees that the role of a “software architect” strongly depends on the context.
“That said, I still have difficulties to imagine a software architect of value who cannot write code (any more). In the end, even Frank Lloyd Wright was able to hammer in a nail straight and sound and in the exact right spot. At least, I wish he was that sort of guy.”

Frank Lloyd Wright seems to have been that sort of guy, and so was Vitruvius, almost 2000 years ago. You’ve got to know at least your (rock)hammer, nails and liberal arts.
When I encounter an “architect” who can’t program, a yellow light goes blinking… In most cases it turns to red. I keep my mind open, I might just encounter one deserving a green light…

I visited the campus of the Frank Lloyd Wright school of architecture at Taliesin West in Scottsdale, Arizona. First year architecture students spend the first year living in a tent, which they can re-build to a building of their own design. Education consists of (among others) theory, building, and creative art forms. Taliesin West as a whole was hand-built by the (student) architects themselves.

Reading the schools’ program, they do not do sheep-dipping either, seems a lot like my preferred style of learning and ‘teaching’:

The Taliesin education provides the foundations for creative, cooperative, independent persons in architecture through active experiential learning. The School has pioneered experiential learning in architecture since 1932 and remains dedicated to the principle of “Learning by Doing” which is interdisciplinary in nature.

Marc calls Bullshit on (perspectives on) SOA (service oriented architecture).

“in the end, it’s about delivering value to the customer, isn’t it?”

I’m having problems with the “Architecture” metaphor applied to software for exactly this reason – software architecture often detracts from delivering value to the customer.

I think it would be wise for those discussing “software architecture” to take a deeper look at architecture than the unthinking stereotype that results from “just using the metaphor”, thereby transforming the metaphor to a (perhaps useful) analogy. Writing this post is my attempt to deepen my own understanding a bit, maybe it will do the same for you
So far, the use of “architecture” seems like a vain attempt of a young profession to borrow credibility from a much older profession. I believe it is time software development learns to stand on its own two feet.
The one thing I’m missing most in discussions and descriptions of “software architecture” is context and history. Building architecture has many “schools”. Each school puts emphasis on other values. An architect, or a team of architects can belong to one or more schools, at the same time, or over time. Or they develop their own style.

Building projects and architects are driven by many factors. For some it seems to be mainly aesthetics:

the piramide @ the Louvre

For others it may be research into new materials:

Eiffel Tower
For others it may be adapting to traditional buildings in the environment:

Shanghai
For some projects (e.g. hanging a photo on the wall) using an architect would be somewhat of an overkill. Using an interior designer might be a good idea in some cases, in the Netherlands they are called “binnenhuis architecten”, meaning “inside (house) architects”. For other projects, an architect is not enough, and an urban planner may be needed:

Scheveningen, the beach front of the Hague

Delft city centre and some of its edges
Other architects, in the vein of Christopher Alexander and Frank Lloyd Wright take a fractal view of architecture. They pay as much attention to why what lamp is hanging where (interior) as to how buildings fit in the (urban) landscape around it:

Monona Terrace Community and Convention Center parking lot overlooking Lake Monona in Madison, Wisconsin, designed by Frank Lloyd Wright

Inside of the convention center, also designed by Frank Lloyd Wright

I used to like the “architect also implements” pattern. Johanna Rothman’s Architects Must Write Code seems to be a more prescriptive variant of the pattern – I’m missing the contexts in which it applies, and contexts in which it doesn’t. Reading Architect as Consultant? it seems Johanna believes architects who don’t program on “the project” can’t work. In Rotterdam we used to say “Kan niet bestaat niet” (‘Can not ‘ exists not). Rotterdam was re-built from scratch, after the city-centre and more was destroyed in a blazing fire, resulting from a bombing in the second worldwar.

If you’re building just a house, “architect also implements” might be feasible, or maybe it is the master builder that also designs. If you’re re-building a city, having the urban planner run around with a hammer and a box of nails would be seen as micro-managemement.

To me the main question is: how does the “architect” know the influence she has on the project, and how does she receive and learn from the feedback about the thing as it is (being) built? For a small project, actually participating in the implementation may be a good idea. I like to pair program with others, and collaboratively develop the (technical) architecture. For a larger project, being present at stand-ups, temperature readings and retrospectives may be a good idea.

We shouldn’t forget that building software is not only about technology. A good “architect” also takes into account the landscape around the software and the people living in it. Diving deep into software development may make one focus on the hammer and nails, and forget about the landscape.

I’m currently involved in an architectural project for a Really Large Corporation that is more comparable in scale to “urban planning”. The role of me and my colleagues is more that of city planners, determining which buildings fit where, and where buildings have to be demolished to make place for highways (I’m consulting on fits and misfits of existing software, software under construction, and assessing the way(s) in which they are constructed and hosted by vendors, internal suppliers and customers).

Actually implementing things, and having done that in the past gives me a perspective that makes it easier to call “Bullshit” on this project. For instance, when SOA related performance issues come up, I can use my experience on implementing a similar system to provide a perspective.
“Implementing” for this particular project wouldn’t make sense to me; I would lose the perspective I need to participate in “urban planning” of multiple (software and organisational) systems.

To me, developing software is about providing value to the customer now and in the future. I prefer to think of “software architecture” as a fractal, taking into acount which types of events have to happen here, placing a lamp if appropriate, and at other times looking at how the buildings fit in the landscape; if and how “architecture” and “architects” provide value depends heavily on the context.

Nynke was apparently thinking along similar lines as I was in Right here, Right now. She writes in Bridging by thought not what it seems?:

It all depends on what significance people assign to a particular “thought”. And whether or not we need/have an authoritative source to refer to, or work from our own related recollections of experiences which can be rather vague, or hard to distinguish well enough, and hard to explain, for becoming (re)useful in an other context.

We often call such recollections “internal babble” or “irrelevant”, in order to more easily ignore associations and messages bubbling up.

By the way, her entry links to beautiful snowflakes under the microscope. Like snowflakes, no two situations are exactly the same, but they can be very similar.

Nynke e-mailed me about the relevant use of a reaction. In case of an emergency, like seeing people in a burning car, careful deliberation is usually not the preferred choice of action, we can trust ourself / our memory telling us that rescuing the shocked people in the vehicle is the best choice.

Other situations require a response, and some thinking before doing. Nynke says “Stop the world… and check possible causes and effects: [...] thinking BEFORE intiating a change, THEN action, that is a response”
I was thinking of how to apply the Satir interaction model in situations where “people” (or me) give a reaction when a response would have been appropriate.

Usually the interaction model is drawn for one person. That kind of misses the point for me; an interaction involves at least one other person. When we prepared the first run of balancing act, I drew the interaction model for two persons:

Seen through the lense of this model, what happens if I give a reaction, is that I speed through the meaning and significance stages, going straight to response. If the other person does the same a fight is the likely result.

“Stopping the world” is a way to break through this. Each person in the interaction can decide for him or herself to slow down. Take a time-out, ask yourself what you saw or heard, and if the situation allows, ask the other. Say “maybe we’re getting in over our head here” or “I need some time to think about this”, or “I’m puzzled”.

Dale Emery uses the interaction model as well. I like what he wrote in Untangling Communication :

By applying the same level of awareness and problem-solving skills that you use in catching problems in software, you will begin to notice the signs of trouble in communication just a little bit earlier. In many cases, that will be enough to trigger you to slow down, walk through the communication process, and get your communication back on the right track.

I’m having fun “debugging” sessions with someone. We share keys from recent events, seeing where we mis-interpreted each other. “What did you see?” “Oh?” “What did you make of that?” “Right… that is not what I intended…”.

“Debugging” sessions are a lot of fun. They help me generate more responses that generate the responses I desire. They do require a level of trust and openness, thatseems to be rare (according to what I see, and what I hear from others) .

When the required trust is not present, I have a debugging session with myself, or sometimes with a third person (e.g. a friend, coach or colleague, in my circles often rolled into one ).

I guess stopping myself in the moment or having a debugging session afterwards helps me create more trust and openness in situations that deserve it. And create more deserving situations over time.

Nynke resurrected her butterfly bubbles blog. In true Nynke style, she started of with an appreciation :

Butterflies are smokin’ hot.

Later on, Nynke shows how she loves to evaporate clouds …

And then she gives a systems thinking perspective on happiness:

Welcome back Nynke!

(people sometimes ask me why I am self-hosting… Being able to provide a space for other people to be creative and seeing them fly is definitely an important factor).

Comics in this post are from the series “Happy Go Lucky” by Repoort.