Yesterday, Laurent wrote about Technology, sweet and sour how he had to pay for WiFi service to notify me about his plane being late. In a sense, it is not in the best interest of airports to let your flight depart on time - the more time you spend on an airport, the more money you spend. For Schiphol Airport, the main source of profit used to be their shopping centre. I don't know what happened after tax-free disappeared, but I guess not much has changed.

The dutch national railways (NS) have developed this system into a fine art. While punctuality of their trains has dropped to unacceptable levels (that was the main reason I bought a mobile phone, and after that a car several years ago...), they have at the same time turned around many of the medium and larger railway stations into shopping malls, with most of the restaurants and snack-places operated by the NS.

If the train doesn't go on time, you are more likely to buy coffee or a snack, so the NS make more money on you. So, as a traveler you might be inclined to think that the goal of a railway or airline system is to bring you from A to B as quickly as possible, there might be multiple incentives for the operators, leading to other conclusions...

Now I would like to have something similar to create readable diagrams of effects quickly...

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.

...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.

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.

For discussion and event information about cynefin and agile, there is now the cynefin-agile mailinglist.

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.

It seems, that as more and more blogs appear, it becomes harder to follow blogs, or even distill trends from blogs, since, as Ton Zijlstra writes, a lot of the information in blogs depends on their context. I personally haven't made much time for reading all blogs I subscribed to recently, since I can't make space for all the ideas generated by them. Don't get me wrong, I'm grateful for all the excellent blogs around, but I can easily 'lose' a day by surfing the blogs.

Marc Evers and I discussed this idea with several people during the xp days and afterwards (Marc also blogged about this ). The idea is, that we'd like more time to explore topics that come up during xp days and regular conferences in depth, and have a place where people from around Europe (and possibly elsewhere) can experiment with new sessions and show them to various xp-days organisers. Most XP days (even though they're completely independentently organised) now have a session submission and review process. This works pretty well, although something kept nagging me. Duncan Pierce spelled it out clearly to me after XP-days London:

We're reviewing session descriptions, instead of sessions.

Even though we're trying to be independent and objective, it is much easier to trust someone you know with organising a session than someone you don't know. I talked to some peope who thought about organising a session for this year, but didn't get around to it. The threshold to start is quite high if you've never done it and are unsure about your facilitation skills. I'm starting to get more comfortable with it myself, based on the good feedback I've gotten over the workshops I've been doing. Even with experience though, getting a session accepted at a conference remains a somewhat mysterious process.

At XP Day Benelux we nevertheless had many new presenters this year. I hope next year we'll have more new presenters, helped by the Agile Open - we're thinking of an open space conference, where the program is decided on by the particpants at the start of the conference. We are looking to grow an overview of supply and demand with respect to workshops on Agile. With a stimulus to present session ideas before Agile Open, as well as questions for sessions from people with only a question or problem and no idea on how to organise a session around it.

One thing we're already looking for from the demand side is more technical and entry-level sessions for XP Day Benelux.

Another reason to organise Agile Open is a recurring theme in many ongoing discussions: how to sustain a viable agile consultancy business, software house or corporate department. These questions are currently mostly debated at the bar or local user groups (and Mary Poppendiecks' XP2004 keynote). I believe it is worthwile to go in-depth on this theme with a larger crowd.

We now seem to have a critical mass of people who want to co-organise, as well as participate so we're going ahead with it. I'm going to send out a mail with a cost-estimate and details so far tonight to those who reacted until now. If you'd like to participate or co-organise or know someone else who might be interested, please contact me or Marc directly. We're looking forward to make this event a reality and expand the ideas we're having so far!