I didn't notice the IT Conversations site before - they seem to have a wide variety of subjects, both IT related and more people-oriented.

A number of books and techniques I've been studying over the past few months have the theme of learning to see. Value stream mapping and causal loop diagrams are two such techniques. Peter Schwartz writes in his book The art of the long view about discussing multiple futures, rather than just the companies' official future. The book Presence: Human Purpose and the Field of the Future discusses seeing things as they are as well.

While writing, I realize a workshop on Perspectives Nynke Fokma created would be about learning to see as well. Time to start working on that one.

Perhaps seeing things as they are is impossible, since seeing is done by perceiving. Nevertheless, striving to collectively learn too see, enables more robust and diverse forecasting.

Steve Denning concludes Use narrative as well as analysis with:

What hampers the creation of such new narratives is of course the corporate culture, which, as we saw in chapter 7 on Taming the Grapevine, holds the existing corporate story in place with an iron grip. The story of what the business is and how it works is not something that has to be argued for, but rather life as it is lived there, a matter-of-fact down-to-earth common sense apprehension of the obvious realities of the organization, which any wide-awake person would grasp if he would just open his eyes.

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.