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?

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.

• Ponderings about 'what is the definition of...' Extreme Programming (on the XP mailing list) , Project, Agile, Leadership etcetera.
• DSDM and RUP have now adopted Extreme Programming, so there seems to grow consensus on what constitutes sound agile programming practices, as well as a growing chance of wider adoption of these practices. In many places SCRUM and XP are also combined.
• The number of conferences on agile is growing rapidly, besides XP2004, OT2004, Agile Universe, there is now also the agile development conference, xp days in the UK, Germany and the Benelux.
• Other conferences are adopting agile, as well as agile session formats. Yesterday I stumbled across Software Development Expo, they have experientials (highly interactive workshops) and an open space conference, as well as a track on People, Projects and Teams.
• The agile community in europe is both starting to face more outward (organising Agile Special Interest Groups to inform managers and software customers) and pulling together (keeping each other up to date on various events).

I'll continue collecting some more signs, If you see some, let me know yours!