Lotus Notes for instance, was released five years after development, and it took another six years before the user base started to really grow. As an example from my own experience, we're using Linux on our laptops and servers, an open source variant of Unix. Unix exists since at least the 70's. In the first twenty years of its' existence, high-priced unix workstations and servers were mainly to be found in universities and corporate research and development environments. Now, after over thirty years, through Linux (and to a lesser extent, FreeBSD and its' derivative, MacOS-X) it is spreading to a much larger user-base.

Starting last December, I am programming on the e-laborateproject. Not exactly a long-running project. It is, however, based on i-tor, open-source software that has developed through several projects starting January 2002. So, I-tor is now in its third year. Having been involved as a coach and programmer, I can recognize several of the pitfalls Joel Spolsky managed in the project. Having been there, I can say, that it is possible to survive those pitfalls, even if you've stepped right in them.

Yesterday, someone described us at CQ2 as "Software Efficiency Experts" . Probably, because we try to eliminate waste in software development, and we continually search for, and find practices that work well for us and our clients.

But what about Effectiveness? It is nice to reduce costs, but if you develop the wrong things, you are getting nowhere. You are getting there more cheaply than otherwise, maybe faster as well, it is all well tested, but it still is the wrong software!

The best way, in my opinion, to increase effectiveness is to eliminate waste in requirements:

• Don’t automate things that don’t have to be automated. If you leave it up to some technical people (I know I’ve been one), you would have everything automated. Instead, automate work that costs much more to do by hand than with software, or automate something so you can deliver much more value to your customer than otherwise possible.
• Program your software ‘just in time’. Delay implementation until you really need the software. It is more effective to invest in software you need now, than in software you don’t need right now, and might never need at all.
• Make sure all the features developed so far provide value. Measure usage of features, remove them if they aren’t used anymore. Unused features cost money for time spent maintaining software, and possibly planning things based on these features. Sometimes it takes time to explore software by using it, to find out which features are really essential and which aren’t.

Now that we are developing the right thing, we can focus on developing the thing right. What works well for us in this respect, is Test Driven Development (which makes reliable software cheaper to build and maintain than unreliable software), Refactoring and some other techniques from Extreme Programming in combination with increasing the personal effectiveness of development team members and better and more enjoyable teamwork through e.g. Retrospectives.

Cost-effective is a nice word to describe this, because it focuses on cost (efficiency) as well as on value (effectiveness).

The metaphor Erik and I use for this these days, is that you have an engine which starts running very efficiently and is very powerful, but the car around it hasn’t changed, so the transmission can’t cope…

Then you can decide to optimize the car as well, but you discover there are holes in the road. Then you can start to fix the holes in the road and so on…

The xp-team is the engine, the organisation around it the car, the organisation around the organisation the road etc.

At XP-Day London, Mary Poppendiecks lecture on Lean Development reminded me of some of the interesting things in Lean Manufacturing and the theory of constraints.

Value Stream Mapping

At least there are tools to identify why your xp-team has diffculty interoperating with other teams within the organisation, and maybe with your customer as well, especially Value Stream Mapping seems interesting. This is where an organisation or team identifies which activities, at what point in time produce value, and other times when there is just waiting for e.g. supplies from outside. An example of elements in a value stream are a finished piece of software waiting for acceptance (not providing, value, just waiting) or customer and programmers discussing requirements (providing value, because the vision for the system is growing). The idea is to look end-to-end end shorten the time it takes a requirement to be turned into deployed software, so that an organisation can respond faster to changing demands.

Kaizen Events

There are also things from Lean Manufacturing with which you can get a whole organisation (the car) to work on their process collaboratively. Kaizen Events look particularly interesting. This is where you take a day with a group, identify things that can improve, and actions to take to do the improvement. I guess the Retrospectives we run are similar, but Kaizen events seem to work with very large groups as well.

Jim Highsmith also hinted at this in his workshop at AYE on team decision making. He gave the example of toyota, where, when developing a car, several car bodies, transmissions engines etcetera are developed. Measurements etc. are taken and discussed with tool-makers, assembly workers, so that when it is time to produce the actual car, there is always a choice of components. When there is a problem with a certain component, it can easily be exchanged.

Interestingly enough, while checking out Dave Thomas’s blog today, I found a related note, "mechanism versus policy" . One size does not fit all, he says when discussing user interface implementations. For expert users, NakedObjects (where users can manipulate objects in the application domain more or less directly through a very thin GUI) might be an excellent solution, since they are free to manipulate everything, while for novices or casual users, a wizard-driven interface is more suitable. Why then, not wrap your NakedObjects in a wizard, and offer the choice which to use to the user?

I have the same feeling about editing web-sites through browsers. As a power-user, I prefer to work with files and be able to do batch modifications with scripts and tools like secure shell. For casual users, the previous sentence might contain 4 strange words (‘batch’, ‘scripts’, ‘tools’, ‘secure shell’), so they’d think, ‘what the …’ is he talking about? The other way around, I feel constrained when having to upload 100 jpeg files one-by-one through an upload dialog - an experience I had when trying to get some digital photos printed recently.

I’ve been walking around with this idea for some time, at least with the frustration of working on one solution (e.g. in this rant), but expressing it to others is much easier now I have a term (Set Based Development) to describe the alternative.

References:

Toyota’s principles of set-based concurrent engineering (text only link )from Sloan Management Review, Winter, 1999, by Durward K. Sobek, II, Allen C. Ward, Jeffrey K. Liker

A new camera sure is fun, but it has one major drawback: I make much more pictures than usual :-). The three categories below contain over 550 images in all. Since I promised several people to put them online, there was no way around but to make myself some scripts to scale the images and generate index files. The program ImageMagick makes this relatively painless. If you want my scripts, just drop me a mail.

Just click one of the images below to see all of the images in the category. At AYE I took so many pictures (about 350) that that one is divided into subcategories...

Visiting the AYE conference and the Grand Canyon in Arizona, USA	XP Day Benelux 2003	A photoshoot with Charles Vermeulen around the Grevelingen lake in Zeeland

Most of the preparation is done individually, by organisers dispersed over several places in The Netherlands, Belgium and France (and sometimes the states). Most of the communication is taking place through e-mail and Internet Relay Chat meetings. It turns out, that often coordination of the work is more work than the work itself... I just put the session descriptions from the website into a document. That took me about twenty minutes, which was much less than deciding who was going to print them ;-). I'm sure we'll find ways to do this more efficiently in the future...

My favourite way of organizing is still doing work co-located, as for instance this picture from a program committee meeting shows:
Nynke Fokma, Peter Schrier and Vera Peeters working on the conference program

Modifying the conference program is quick and easy during a pc-meeting. We take the latest version from our website (yes, the website is conventient for broadcasting the program to participants and session organisers), transfer it to post-its, and juggle around the program on a whiteboard. We then take a photograph of the end-result, and someone (usually Vera) ensures the broadcasted program reflects the one on the whiteboard.

So, I'm almost off to the conference location, to do a last check of the rooms, the internet connection and maybe do some set-up work already. May-be I'll see you tomorrow. I'll put some pictures up somewhere next week.