I did not necessarily agree with his views or the way he treated other people, I do however appreciate his ongoing efforts to stir up dialogue and debate about issues in our society. If someone feels attacked, use a pen or the law to react, not a gun...

Here you can find my ruminations on (agile) software development practice, systems thinking, as well as rants against ‘the hype du jour’ and sometimes system administration tips. I call it a ‘column’ as that is what this form has been called by (dutch) newspapers for a long time. On the web, it is hyped as ‘new’ and is often called a blog.

You can find contact details and more information on my professional activities at www.willemvandenende.com .

About the software serving this column

This site is running on a combination of Apache and RubLog, a piece of software created by Dave Thomas. If you want to use this software, you can download the source code and installation instructions from rubyforge RubLog is a simple file-based web log/wiki. It has a few distinguishing features:

• It accepts input in a variety of markup formats. HTML, plain text, and RDoc formats are supplied by default, along with a handler for Usemod wikis. More can be added without much effort (this file is in RDoc format)
• It works from conventional files and from CVS/RCS repositories. This is useful is multiple people are using the same blog: have them check stuff into CVS, and point the blog software at the repository.
• It supports category-based and time-based access (and combinations of the two).
• Output styles are pluggable: a standard example and a style to support printable documents are provided.
• It supports WikiWord-style links between articles (in RDoc mode).

RDoc License

RDoc is Copyright © 2003 Dave Thomas. It is released under the same terms as Ruby.

They distrust spontaneity because it threatens the perfection of their formula for how things should be. It's one example of the reverence for the abstract and the material, over the relationship and the people (more on this soon). It leads to the deadening formulaic "have a nice day" customer service instead of allowing human beings the possibility of creating some fun together in a way that works for them in the moment.

If you follow the first road, you could get some living software, that lasts a long time, because the users get to live in the software, and become inhabitants, rather than just users. If the inhabitants really feel they have an influence of where the software is going, you might get viral marketing. This approach is scary, since it forces the product developer to relinquish some control over the product to the inhabitants.

The second approach doesn't prevent success: the pre-defined vision doesn't change much, so it is probably easier to create pre-defined marketing material for it. If the formula doesn't stick, you're in trouble though. You also risk continuing friction between your vision and that of the users.

In complex situations, such as software projects and the teams that work on them, there's never such a thing as "the problem". The sense that something is wrong may be the start of a break with routine - the start of a problem-solving process.

From the list, I prefer to reinforce what works, to compensate for natural tendencies to think in negative ways about problems.

Another favourite of mine (although I'm not quite sure if it fits in Laurent's list), is Reframing - taking a different perspective so the problems at hand disappear and the situation looks entirely different. Marc Evers pointed me to a blog entry by Ton Zijlstra about information overload, Every Signal starts out as Noise which contains this example:

there is no such thing as information overload. It does not exist.

When trains were first introduced passengers suffered from jet-lag like symptoms, even at speeds as low as 20 km/h. Most likely because for the first time sensory input became asynchronous. What you heard and smelled (the train, people in the car with you) did not coincide with what you saw (the landscape passing by). We adapted, we have to do so now.

individuals and interactions over processes and tools

In the nineties, I used to be fond of CASE tools and the like, and wonder how to put an iterative planning in MS Project... Over the years, my preference has shifted more and more to individuals and interactions, as I have seen no evidence of higher productivity through CASE tools or software planning tools, but have experienced firsthand the enormous power of simple face to face planning and design meetings, with open communication and simple tools such as index cards, whiteboards and physical planning boards.

Rachel Davies just wrote a piece on using index cards with five reasons to prefer index cards over an online story repository, and five reasons for exactly the opposite. The quote below stresses to me the importance of looking for the root cause behind the wish to use electronic story repositories as a solution:

When making a choice in what medium your team uses for stories consider this:

• index cards support more extreme behaviours - sitting together and customer conversations
• use of electronic tools may be used to support larger teams with a customer who may be off-site. They may appear more effective for larger organisations but their use may mean that issues of team size and location are not challenged.

On the collaborative design side, someone asked me recently which code-generating UML (Unified Modeling Language) tool I would recommend. This is a simple question that gives me enormous difficulty in answering. I have studied CASE tools and the UML intensively in the past, and since I saw no benefits delivered, I lost interest about five years ago. Since I lost interest, I have not kept up to date, I have a nagging little feeling I might have missed something. But the feeling remains little - I have not heard overwelming success stories. Maybe I'll go into some of the reasons I lost interest:

• UML was not computationally complete, so creating executable models which was the pipe-dream of CASE tool builders would remain exactly that. Computer programs are already executable models, and while creating (by necessity more) abstract graphical representations of the program can be useful for understanding, creating a program from the diagram alone was not an option. That doesn't mean I find graphical notations useless for performing programming-like activities with a computer - only that the UML is not a suitable notation for doing so. I think it works better within a reduced scope, such as e.g. a modular software synthesizer like Reaktor which I enjoy using.
• UML tried to include everything and the kitchen sink, and from version 1.0 onwards, it became only more elaborate. Trying to think about a design with dynamic models hrough UML made my head spin, and gives a team an extra chance to get stuck in analysis paralysis, e.g. by deciding which of the bewildering amount of notations to use, and determining exactly what the sementics are of a particular bubble or square...
• With respect to CASE tools, Round-trip engineering (going from diagrams to code and back iteratively) is probably still difficult, although I heard poseidon does a reasonable job.
• Using case tools takes a lot of work and wasteful steps. I remember trying to use Rational Rose, which had a dialog for creating a class with like twenty tabs...

That is not to say, there is no value in the UML at all, I just value brainstorming with colleagues more... I use UML sparely. Mainly informally with a team, gathered around a whiteboard or a table with index cards (of which we take photographs afterwards, if anyone wishes to keep the diagrams) solving a particular problem.

In case you might need to create a more formalised view of your diagrams. Martin Fowler just put up a list of uml sketching tools, I used to use the visio templates he mentions as well, and they worked pretty well.

I've been recently hosting workshops with various kinds of games, and can corroberate what Rebecca writes. Games are not only educational, they are fun and allow the players to experiment, and connect with one another - since usually the players haven't met before. If the game works well, it takes quite a bit of effort to get to the next item on the agenda :-). A brief game after lunch also works well to get energy back into the meeting. I haven't tried playing games regularly in day-to-day work situations. It might be a worthwile to try, as it loosens up a group, takes the minds of off the routine and allows (if done well) equal participation by everyone involved.

Lately, I've been doing a lot of thinking. Time to start playing?