me.andering – Willem van den Ende

Yesterday, I was reading again in Quality Software Management volume 4 – Anticipating Change by Gerald Weinberg. In chapter eight I found a description of Virginia Satir’s Five Freedoms, which goes nicely with the Learning to See theme from the day before:

• 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

these originate from The Satir Model: Family Therapy and Beyond.

Rachel Davies points to A history of patterns on the c2 wiki, which reminds me of something I have been ruminating over for the past month (and now I might be ranting ). The history on that page ends in 1999. What happened to Design Patterns since then? So far, I am somewhat disappointed about the effect Design Patterns has had on software development practice.

Design Patterns have had a positive effect, in that they facilitate communication amongst programmers, by giving them a common verbiage. They can use words like Composite or Decorator to abstract complex software structures and behaviour. I haven’t seen many pattern languages for programmers and users (or, to stretch the building metaphor a bit further, inhabitants), like e.g. Tools and Materials, as Alexanders’ ‘A Pattern Language’ does. The use of patterns in practice seems limited to the catalogue in the Design Patterns book – most programmers that use Design Patterns don’t seem to bother reading Alexanders’ books or the PLOP (Pattern Languages Of Program design) series.

On the pattern languages side, I was hoping that something like ‘Domain Driven Design’ by Eric Evans might bridge the gap between programmers and inhabitants. These comments on bookshelved lead me to believe patterns were merely used for the format, not the spirit of the book (I have yet to read it for myself to make up my mind).

It is possible, that I’m just being impatient, and patterns are not disappearing as just a fad. If so, they are likely to reoccur again. The use of patterns is probably ancient, as this example How “Pattern Books” Fueled England’s First Speculative Real Estate Market shows there where pattern books around 1600 explaining how the real estate markets worked.

Maybe after the first flurry of lets’ describe everything in pattern form, we might yet see some actual pattern languages (rather than mere pattern vocabularies) for use by all inhabitants of software.

I wrote earlier about the agile open space conference we’re going to organise in Belgium, in the Spring of 2005. It is most likely going to take place in first half of May. We were thinking of late april, right after the Scrum gathering. There were some public holidays in that period, so that doesn’t fit.

You can now post your interest in participating at the agile open wiki. The goals of this conference are set by the participants, so you’re welcome to add your goals to the wiki, or discuss them on the Agile Open mailinglist. The current round of goal brainstorming already generated some interesting ideas. We seem to be drawing people interested in Agile from inside and outside the software development community.

Rachel Davies blogs about the second version of Extreme Programming Explained by Kent Beck. Apparently it is a complete rewrite from the first version, with revised principles, practices and values. Like Mary Poppendieck, Kent Beck is now also apparently making the connection between The Toyota Way and Agile Software Development explicit.

The second edition of Extreme Programming explained now also contains more graphics apparently. The three rivers’ website contains some samples: Extreme Programming in Pictures. These are nicely hand-drawn mindmaps that seem to show the systems thinking perspective behind Kents’ new take on XP. The first edition of Extreme Programming Explained also had that systems thinking thing going, since the practices and values form an interconnected whole – finding out how the whole is formed was left as an exercise for the practitioner (which was educational ). I hope the new book goes into some more depth explaining some of the ‘soft’ practices and the values.

Johnny Moore is discussing Brands as Living Systems.

He talks about companies wishing for word of mouth, but not really word of mouth:

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.

Developing software products has similar problems: do you really really want user involvement, or do you only want to develop the product in a formulaic way?

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.

Laurent Bossavit writes about Problem-picking patterns:

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.

.

The Manifesto for Agile Software Development (which I subscribe to) values

individuals and interactions over processes and tools

, while recognizing there is value in processes and tools, individuals and interactions are more important. Two areas where this preference is generating choices (and, depending on the organisation, debate) is planning of functionality and collaboratively designing software.

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 just got news that two sessions I co-submitted for XP Days Germany in Karlsruhe have been accepted. The Systems Thinking Workshop, together with Marc Evers and Pascal van Cauwenberghe

and Who has dropped the ball? Understanding Team dynamics together with Marc Evers. Both workshops are a continued development from the systems thinking workshop at xp2004.

Rebecca Ryan blogs about thought is the most productive form of work not. Thought is NOT the most productive form of work. PLAY is. PLAY engages all of our senses. It moves muscles other than our cerebrums. PLAY rejuvenates, makes room for risk, and reminds us what it is to feel truly alive

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?

I’ve been reading some books that revolve around taking long term perspectives. How Buildings Learn, by Stewart Brant, looks a few centuries into the past, to see how some buildings adapt to changing circumstances and some don’t. The Clock of the Long Now by the same author inspires to look many millenia into the future. The Art of the Long View by Peter Schwartz is about scenario planning, a way to identify multiple possible futures and create options for those futures.

What might we get if we apply a long view to software develoment? What if we wouldn’t build software just for tomorrow, but for the coming several hundred years, like we build railroads and bridges for instance. Marc Evers pointed me to an article by Dan Bricklin, Software that lasts 200 years in which he identifies some possible answers to these questions. He argues, amongst other things, that no single company will be able to support an application for that long (and as applications are networked, that also means connections to other appications) and that in fact a durable kind of support eco-system is needed. This has interesting consequences on e.g. the future of funding Open Source. As he puts it in his conclusion Open source software discussion should be about keeping the trains running on time and not just saying it should run on Linux. The discussions should be about funding the companies needed in such an ecosystem and assuring their sources of healthy revenue. The code is not the only part of the equation, and leadership for all aspects of the ecosystem need to be addressed.

An aspect a friend of mine suggested that goes relatively unnoticed, is the tendency of some companies (e.g. Microsoft) to start patenting their data-formats and even encrypting data you created with ‘your’ word processor (if you read the licence contract, you will know it is not yours…). This will make it extremely hard to get to this data in the future. My friend suggests to put legislation in place, that forces any application that stores data, to be able to export that data to a plain text format, so it can be reconstructed in the future. I think that open standards for protocols and data formats are essential for longevity of data and applications.

It might also be necessary to archive not only the data and the programs, but also the hardware they run on. The Clock of the Long Now has an instructive example of someone trying to re-enact a virtual reality show he created on a Commodore 64. Eventually, this person got lucky because volunteers have created commodore 64 emulators, and someone also put his virtual reality program online, complete with the manual. If we want to keep an accurate historical record for the future then, as Dan Bricklin puts it: serendipitous volunteer labor must not be a major required element.. For instance, tens of thousands of open source projects now rely on SourceForge. What happens if the company supporting it looses interest? Will only the cool projects be saved by enthusiasts?

Being occupied with agile software development, I notice a tension. On one hand, we focus on creating software for today, not building things that are not yet needed. On the other hand, we involve all stakeholders (which might uncover long term consequences), strive to deliver a minimal feature set (so in the future, less features need to be re-created if software archeologists would like to re-run the program) and prevent defects.