me.andering – Willem van den Ende

Rachel Davies blogs about the second version of Extreme Programming Explained by Kent Beck. Apparently it is a complete rewrite from the first version, with revised principles, practices and values. Like Mary Poppendieck, Kent Beck is now also apparently making the connection between The Toyota Way and Agile Software Development explicit.

The second edition of Extreme Programming explained now also contains more graphics apparently. The three rivers’ website contains some samples: Extreme Programming in Pictures. These are nicely hand-drawn mindmaps that seem to show the systems thinking perspective behind Kents’ new take on XP. The first edition of Extreme Programming Explained also had that systems thinking thing going, since the practices and values form an interconnected whole – finding out how the whole is formed was left as an exercise for the practitioner (which was educational ). I hope the new book goes into some more depth explaining some of the ‘soft’ practices and the values.

I wrote earlier about the agile open space conference we’re going to organise in Belgium, in the Spring of 2005. It is most likely going to take place in first half of May. We were thinking of late april, right after the Scrum gathering. There were some public holidays in that period, so that doesn’t fit.

You can now post your interest in participating at the agile open wiki. The goals of this conference are set by the participants, so you’re welcome to add your goals to the wiki, or discuss them on the Agile Open mailinglist. The current round of goal brainstorming already generated some interesting ideas. We seem to be drawing people interested in Agile from inside and outside the software development community.

Rachel Davies points to A history of patterns on the c2 wiki, which reminds me of something I have been ruminating over for the past month (and now I might be ranting ). The history on that page ends in 1999. What happened to Design Patterns since then? So far, I am somewhat disappointed about the effect Design Patterns has had on software development practice.

Design Patterns have had a positive effect, in that they facilitate communication amongst programmers, by giving them a common verbiage. They can use words like Composite or Decorator to abstract complex software structures and behaviour. I haven’t seen many pattern languages for programmers and users (or, to stretch the building metaphor a bit further, inhabitants), like e.g. Tools and Materials, as Alexanders’ ‘A Pattern Language’ does. The use of patterns in practice seems limited to the catalogue in the Design Patterns book – most programmers that use Design Patterns don’t seem to bother reading Alexanders’ books or the PLOP (Pattern Languages Of Program design) series.

On the pattern languages side, I was hoping that something like ‘Domain Driven Design’ by Eric Evans might bridge the gap between programmers and inhabitants. These comments on bookshelved lead me to believe patterns were merely used for the format, not the spirit of the book (I have yet to read it for myself to make up my mind).

It is possible, that I’m just being impatient, and patterns are not disappearing as just a fad. If so, they are likely to reoccur again. The use of patterns is probably ancient, as this example How “Pattern Books” Fueled England’s First Speculative Real Estate Market shows there where pattern books around 1600 explaining how the real estate markets worked.

Maybe after the first flurry of lets’ describe everything in pattern form, we might yet see some actual pattern languages (rather than mere pattern vocabularies) for use by all inhabitants of software.

Yesterday, I was reading again in Quality Software Management volume 4 – Anticipating Change by Gerald Weinberg. In chapter eight I found a description of Virginia Satir’s Five Freedoms, which goes nicely with the Learning to See theme from the day before:

• The freedom to see and hear what is here, instead of what should be, was, or will be.
• The freedom to say what one feels and thinks instead of what one should.
• the freedom to feel what one feels, instead of what one ought
• the freedom to ask for what one wants, instead of always waiting for permission
• the freedom to take risks on one’s own behalf, instead of choosing to be only ‘secure’ and not rocking the boat

these originate from The Satir Model: Family Therapy and Beyond.

A while ago, I wrote about the relative uselesness of Rehashing.

Every now and then, someone else will ask me questions about the past, since I don’t rehash voluntarily anymore. I prefer to work on the future. Marko van der Puil asks me how I reconcile that with facilitating retrospectives.

To me, retrospectives are as much about the future as they are about the past. We collectively investigate a set period in the past, to achieve closure on the past, and determine concrete actions for our future. If a retrospective doesn’t turn up personal and collective actions for positive change, we might as well have skipped it altogether.

Rachel Davies is blogging about what for me was one of the highlights of XP Days Londen 4 – a presentation and workshop by Dave Snowden about Cynefin, a framework for Sensemaking. You can find more information about this in the paper Sense Making in a Complex and Complicated world by Cynthia Kurz and Dave Snowden (IBM Systems Journal, Vol 42, No3, 2003).

Luckily, I read the paper before going to the workshop – that left some room in my head to fill some of the gaps in my understanding the paper had left me with, rather than being overloaded (as most of the workshops’ participants seemed to be. It made quite an impression). By the way, the reason I read the paper was that I was wondering if paying to attend this workshop was worthwile. Since after reading I still had many puzzles, I thought it would be, and it was. I’m still ruminating over these ideas.

One of the ideas that resonated most with me was the Cynefin Domains model. It is sort of a two-dimensional matrix. The paper has a nice graphical depection that makes it clear that the boundaries between the domains are semi-permeable. One way I understand this model, that an organisation can move from one domain to another by making sene of where it is now – and seeing if the paradigm it currently applies for e.g. decision making is appropriate. I’ve transcribed the four domains into a table:

To give one illustration (more in the paper mentioned above) Systems Thinking and Scenario Planning fit into the Knowable domain. Someone at XP Days London asked me if I didn’t find it annoying that Dave Snowden sort of mowed the grass before my feet; Marc Evers and I were hosting a Systems Thinking workshop at XP Day London the next day.

I responded that I was very glad for the context setting Dave Snowden had done – we used the Cynefin Domains model in the introduction of our workshop, as we are constantly looking for a better way to briefly introduce Systems Thinking at the start of a workshop. I am not Systems Thinking it is one of the techniques I use to make sense of the world around me, if and when appropriate.

So how do I believe this model relates to appropriate forms of setting up an organisation? I immediately related this to Gerald Weinberg’s Cultural Patterns (aka Shooting and Aiming Stances) for organisations, so I came up with this mapping:

The Congruent cultural pattern would be equivalent to sensemaking: taking self, other and context into account, and choosing (and changing, if the domain shifts) a cultural pattern that is appropriate. When I was reading the wiki page on Cultural Patterns I realized I forgot Oblivious. Thinking about it now, I find it hard to place. Maybe the oblivious cultural pattern is not realizing where you are, and not making any choice for an organisational form.

The connection was somewhat natural, since with a group of systems thinkers we’ve been thinking about how to move from one cultural pattern to another. In the workshop and paper, Dave Snowden says they’ve identified a number (27 if I remember correctly) of specific choreographies to move from one domain to another.

For instance, working iteratively is a way of moving from Known to Knowable and back, and moving from Knowable to Complex can be done by Exploration (to move in the opposite direction, use Just-In-Time Transfer).

Dave Snowden talked about the relation with eXtreme Programming. At first sight, I would place XP at the Known/Knowable boundary, because of the Iterative aspect. He seemed to place it in the Complex domain which left me a bit puzzled.

The way I could place it there, is that XP also has an exploratory component (e.g. doing spikes), and the extremely short iterations make it possible to investigate multiple alternative solutions (relating to what Snowden calls probes, exploration and to Set Based Development). Another component to XP/Agile is delaying (design) decisions as long as possible, which relates to just-in-time transfer.

I just noticed I’m using a lot of emphasis in this post. It seems to have a high jargon density. I’m looking forward to the article collection promised at cynefin.net, so I could upgrade some of the emphasized words to hyperlinks. In the meantime, I recommend you read the paper if these ideas interest you. I’m also interested in any comments you may have on this blog entry, as I’m busy understanding the Cynefin paper.

I’m still busy making sense from the Cynefin framework for sensemaking (for a brief introduction on how I see it so far, see the previous post on Cynefin). I’m puzzling on how eXtreme Programming could fit in several domains, and how choreographies from one domain to another would work. Richard Veryard, also raised the question about XP, in his blog post on a brief history of methods. He places XP in the ‘known’ domain. As I was re-reading the Cynefin paper this week I’m making some progress in understanding it. Or so I believe. As my thoughts went in many directions, I created a mindmap about how I could place XP in the various domains.

So far I find the chaos domain the most puzzling. I’m not sure thinking about software is appropriate in that domain. In chaos brainstorming and deciding on a choreography to one of the other spaces (preferably complex) might be more appropriate. I can see how XP could fit (and misfit) in known, knowable and complex – although in each context it has a different effect, and you can use it for a different purpose. I hope to work on the mindmap a bit more and then write a longer post about it.

Now I’m back from my trip to Consultants Camp and San Jose, I’m still sleep-deprived and jet-lagged.

Neverheless, I went to the open space conference of the Dutch Society for Organisational Learning. The theme of this day was Unlearning. I had a great day, meeting interesting people from a variety of fields. Marc Evers and I put up a play of Warped Juggle on the planning board. We had a cozy session with five participants, which gave us some new perspectives on the Satir Change Model, amongst others – Unlearning happens during the chaos phase, and with scenario planning we might welcome chaos, rather than experiencing it as painful. We put up more output from this session on the SystemsThinking.net wiki.

Laurent Bossavit is writing about Recording design decisions. I gave up on the idea of recording (all) design decisions years ago, when I was doing research into that topic at the University of Twente, together with Marc Evers. We tried to come up with a formal model that would trace each decision back to a corresponding piece of code. The complexity of instances of that model was mind-boggling, especially if you start taking the evolution of source code over time into account.

We came to the conclusion, that the number of decisions involved in creating any computer program is too large to record meaningfully. Another conclusion we arrived at, was that many decisions are made at lightning speed inside our head, and some decisions we are unable to articulate. I think that is one of the underlying reasons attempts at documenting software in detail often fail (besides the fact that very few software people enjoy writing prose).

One thing I usually do when working with a team, is to regularly (every hour at least) check in code to the version control system, and add a one-line comment when checking in. These comments reflect the closest practical thing I found to keep a trace of design decisions. I noticed after some time, that we rarely look back on the comments – I think it is because team members find it more effective to ask each other ‘why is this part built the way it is’, re-create the assumptions underlying the design by asking ‘why’, and either working from those assumptions, or re-defining the assumptions and start refactoring.

The best way I found to get design decisions out in the open is to do Pair Programming, so two programmers are forced to articulate a larger part of their design decisions. Even then, it is recommended practice to code out versions of an idea as a Spike Solution, if a discussion takes to long, and continue the discussion after two versions of the idea are complete: sometimes an idea is more easily expressed in source code than it is in natural language…

I’m asking myself: Why would I want to record design decisions?. I haven’t felt the desire to do that since leaving university. If the design is simple, and we keep requirements as automated acceptance tests, we are free to change the design whenever we want to. The acceptance tests provide the context we need to start finding appliccable (design) patterns. Perhaps the desire to record design decisions is an indicator we are building overly complicated software?

Rather than making an effort to record more design decisions, we can get leverage from simplifying our design and doing more automated acceptance testing.

At the beginning of the year, I noticed several people announcing which programming language they are going to learn this year. They follow a recommendation by Dave Thomas and Andy Hunt to learn a new programming language every year. I’ve been programming for over twenty years now, and in that time have programmed in a lot of programming languages. At first, I couldn’t come up with anything. I saw many people start trying ruby or smalltalk. Been there, haven’t completely done that. So, like many other people I’m getting (re-)acquainted with Smalltalk by programming in squeak smalltalk.

After some thought and blog-reading, I came up with two possible things to explore. I’m not so much interested in particular languages, maybe more in exploring different programming paradigms. Following discussions on e.g. the squeak mailing list on the future of CPU’s, it is obvious something is bound to change. CPU’s can hardly be made more complex than they are now (for they will be very unreliable) and can’t go much faster with regard to clock speed (barring other technologies such as light-switching). Two avenues that seem worthwile to explore are massively parallel CPU’s – CPU’s with multiple cores, and digital signal processing with FPGA’s (Field Programmable Gate Arrays).

Most popular programming languages don’t support parallellism well. I attended a tutorial on Java threads – it is so easy to create non-obvious, hardt to trace defects with them, that it is better to use them as little as possible. Patrick logan is writing about programming in Erlang:

I want to understand how to think in terms of processes being about as cheap to create as objects are in other languages.

Bill Clementson has a report about disruptive programming languages, reporting from a workshop he attended:

…the opportunity for concurrent programming to be a distruptive technology is in that many applications are either explicitly or implicitly concurrent or distributed but are poorly catered for by concurrency features (OS threads, language threads, RPC) in use today. If a language provided superior concurrency capabilities, it could displace more popular languages in specific application areas. Once the “innovator” language assumes prominence in the “niche” area, it would expand further in usage and popularity and potentially displace the more popular languages in other areas as well.

The report has an interesting comparison of reliability of the Apache webserver versus one written in Erlang. The Erlang webserver is able to handle far more concurrent connections.