Archive for January, 2005

Lack of time leads to simple automation

Friday, January 14th, 2005

In the early days of the dot-com boom, reading the book Patterns of Software by Richard Gabriel made me aware of the risks of having too much (venture) capital for a project. If a project has too much money allocated to it, there may not be enough driving force to eliminate wasteful work.

One of these wastes is not automating repetitive tasks. Fast Company Now guest host Keith Yamashita refers in Systems thinking: The Product to a speach by eBay founder Pierre Omidyar:

So people often say to me – “when you built the system, you must have known that making it self-sustainable was the only way eBay could grow to serve 40 million users a day.” Well… nope. I made the system self-sustaining for one reason:Back when I launched eBay on Labor Day 1995, eBay wasn’t my business – it was my hobby. I had to build a system that was self-sustaining… …Because I had a real job to go to every morning.

When you’re the sole programmer and product visionary, this is doable. Your lack of time will force you to choose between glitzy new features and stabilizing the system (e.g. by preventing and removing defects and automating repetitive tasks). I’m curious how eBay does it now it has become much larger, and more people will likely be involved in decision-making and programming…

More blogging and aggregation

Friday, January 14th, 2005

Last week, a new weblog by Nynke Fokma went live, called Bommelstein. Welcome Nynke! . Nynke writes, amongst other things, about Systems Thinking and (In)Congruent Communication .

Recently I’ve been working with Marc Evers and Nynke on a site about systems thinking, with a weblog-aggreggator containing weblogs from systems thinkers and a wiki. We made this invitation:

Have you noticed that changing your software development method changes your organisation?

Wondered why the customer can’t keep up with the programming team?

What to do about it?

How to get a team to use unit testing?

Doubted whether the lack of unit testing is really the team’s biggest problem?

We found systems thinking to be a simple but powerful technique for finding answers to questions like these. When seeing organisations, projects, and teams as systems consisting of interrelated and interacting parts, one enables a relaxed focus on relationships as well as the whole and can easily reveal self-reinforcing feedback loops and not-so-obvious causal relations before they trip us up.

Would you like to change the rules of the game?

Figure out what you can do as systems thinker?

With a little self-esteem and imagination?

Co-create flexible processes congruent with desired products?

Increase awareness of your self and what is going on around you?

Turning on feedback loops?

Weave your thoughts with others in a wiki?

We cordially invite you to join us on

Freemind – free mindmapping tool

Friday, January 14th, 2005

I couldn’t get someone to understand my hand-written mindmaps. Hubert Smits pointed me to freemind a cross-platform open source mindmap diagramming tool. It is very easy to install (RPMs for linux are included) and well thought-out: I can create a mindmap in minutes about as fast as taking ordinary notes – the most important actions are easily done with the keyboard. I’m usually not so thrilled about computerized diagramming, but freemind is easy and quick to use. Below, I quickly made a mini-mindmap to show how it works

example mindmap

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

Learning to See

Friday, January 14th, 2005

I was at Marc’s yesterday, brainstorming some more topics for workshops. One thing that came up, about which we did not have a clue on what a workshop about the topic would look like, was Learning to see things as they are, rather than how they should be. This capacity enables one to see the future(s) more clearly, and have an open dialogue within a group about the future. If you don’t know where you are, how do you know where you’re going to?

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.

Lightning Writing

Friday, January 14th, 2005

Today I’m working on an invited session for SPA2005 with Laurent Bossavit, shepherded by Rachel Davies . It is about freewriting, the session is called Lightning Writing Workshop. Freewriting consists of setting apart 5 to 10 minutes to write in one go continuously, without censoring yourself. Getting Started with Freewriting contains a brief explanation of the process, as well as some useful links on the topic. My main motivation to co-create this workshop with Laurents is to get myself restarted with freewriting, and explore one more way of writing in-depth.

I just tried a 5-minute freewriting exercise on a question Marc Evers asked me today: What does product management mean? The exercise didn’t come out with a specific answer, it did turn up some hints about what I think it should be: about a long-term vision translated in a concrete fashion to day-to-day actions, where software is developed in small increments without taking a mortgage on the future. I also started writing about some situations where I succeeded or failed to collectively do effective product-management with clients and developers on one hand, and consulting clients of mine whom I am helping to deal more effectively with outsourcing on the other hand.

As I was writing this, I was thinking I haven’t done much freewriting before. In fact I have, but I wasn’t aware of it. I have three or four notebooks filled with notes and diagrams, written at moments when I was contemplating my work. Amongst others, it is promoted in Becoming a technical leader by Gerald Weinberg, to set a few minutes apart every day to write about what you experienced that day. I did that for a few weeks in a notebook, but found it difficult to keep it up. On the other hand, I am writing about my experiences every day in e-mail messages to my friends and sometimes a blog-entry such as this one.

One of the reasons it may be hard to write regularly, is that writing is one of those things that is always important, never urgent. Freewriting may help to get started, as it takes only five minutes to begin.

Getting good at anything requires lots and lots of practice, and sometimes letting go of the critic inside you, so you can enjoy small successes and failures.

Dancing With Systems

Friday, January 14th, 2005

While doing a search for systems thinking related sites, I stumbled across an article Dancing with Systems by the late Donella Meadows, reflecting back on her long experience with systems thinking and systems thinkers. I can identify with many things in the article, so I find it hard to choose an appropriate quote. I chose the one below, as it has some relevance to the current elections in the US, soaring oil prices, as well as, in my opinion, a lack of feedback driven policies in the Netherlands. Also, I and others are currently struggling to explain feedback driven policies in organisations.

Make feedback policies for feedback systems.

President Jimmy Carter had an unusual ability to think in feedback terms and to make feedback policies. Unfortunately he had a hard time explaining them to a press and public that didn’t understand feedback.

He suggested, at a time when oil imports were soaring, that there be a tax on gasoline proportional to the fraction of US oil consumption that had to be imported. If imports continued to rise the tax would rise, until it suppressed demand and brought forth substitutes and reduced imports. If imports fell to zero, the tax would fall to zero.

The tax never got passed.

Imagine for a moment: what would have happened now with respect to oil if this policy got passed 25 years ago?

On my way to consultants’ camp

Friday, January 14th, 2005

If you’re reading this, it means I managed to get wireless LAN working somewhere. I’m sitting at the airport in Denver, Colorado waiting for a very local flight to a place called Gunnison. I’m going to attend Consultants Camp, a one week open space conference. I have been to the smaller european offshoot of this event. I’m curious about the one here.

It takes place in Crested Butte, Colorado, which is located at an altitude of 3 km. Anyway, if you would like to meet up with me while I’m in the USA, send me an e-mail at willem – cq2 – nl (replace dashes with an @ and a . respectively). I’ll be in Crested Butte until September 13th, the week after that I’ll be in Palo Alto, California. I’ll be back in the Netherlands on the twentieth.

Extreme Programming values enable more effective software development in the large

Friday, January 14th, 2005

Marc Evers Just points me to this blog entry by Erik Meade about XP values and XP in the large. Erik points to an interesting article in computerworld Sabre takes extreme measures. Large scale deployment of XP practices has enabled Sabre to achieve a 42 % productivity increase. Within such an environment (as in many) the XP practices and values indicate what to strive for. Even if, while striving, you don’t get to have all levers up to a 100%, you can still achieve a dramatic increase in productivity. A quote from the computerworld piece:

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.

The Importance of being Idle

Friday, January 14th, 2005

Through Evelyn Rodriguez I stumbled across The virtue of idleness by Tom Hodgkinson.

Idleness as a waste of time is a damaging notion put about by its spiritually vacant enemies. Introspection could lead to that terrible thing: a vision of the truth, a clear image of the horror of our fractured, dissonant world.

I have gotten some of my most disruptive ideas when forced to stay in bed for days because of illness. For instance, the decision to become an independent consultant came to me, when I was admitted to hospital for over a week, back in 2001. I was striving hard to get various things of the ground (and working hard to that effect as well). When I was admitted to the hospital by surprise (so the neurologist could run a lot of tests in a short time) I was, so to say, stopped dead in my tracks.

Having nothing to do for most of the day besides a little reading, I pondered what things I could do to increase my effectiveness. After a few days of lying in bed, I realized I was not getting anywhere. This was disruptive, because until then I was living under the assumption I had found my dream job. I realized it was time to do something else.

After a week at the hospital, I became an outpatient. I stayed at home another week. Because of the heavy antibiotics I got, I was too tired to do much, so I spent most of my time just sitting in the garden (yes, summer can be an excellent time to be ill). Spending this idle time, with some reflections on life which hospital visits seem to bring inevitably, was a major factor in my decision to explore independent consulting as an option.

It is not guaranteed to work – not every time I get lay in bed ill, I get disruptive ideas. Introspection remains scary. There have been times I was scared to go on holiday, in case I might get those disruptive ideas. Especially, since at first, I have only an idea of what is wrong, not what could be done to remedy the situation. I’m trying to spend more idle time now.

When I started my independent consulting, I imagined I would have more time like when I was in university – just visiting people, hanging out, chatting on the couch. Instead, I have worked more hours than ever before… So recently, I’m making more time to travel and hang out with friends and colleagues.