• 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

For example, fewer than 10 bugs surfaced in Release 10 of its Profit Manager software in the two months after it began shipping to airlines in December 2002. Now, 16 months later, just 100 defects have been found. Release 10 was written in Java, while Release 8 was written in C and C++. But Sabre says it was XP, not Java, that produced the dramatic quality improvements.

I used to believe choice of programming language to be very important to productivity. I now believe close customer collaboration and test driven development deliver much more value, as the Sabre example shows as well. Although, as Sabre moved from C++ to Java, they also were likelely to profit from automatic garbage collection (so programmers have to worry much less about allocating memory, a common source of defects in C and C++ programs).

If you want to find out more about agile/XP software development in large projects, I recommend Jutta Eckstein's book Agile Software Development in the Large.

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.