Documenting Wiki2Go

No time to write in the blog or continue on the Theory of Constraints series today.

I’ve been updating the documentation for the Wiki2Go wiki that is used to host, amongst others, this site. It’s quite easy and fast to set up if you know what you’re doing. And I do. But others are now setting up Wiki2Go sites and are asking how to do it.

As Fred Brooks says “A programming product costs roughly 3x as much as a program.” As others start using and developing Wiki2Go I have to invest in (user and developer) documentation, installation tools, administration user interfaces, deployment…

Brooks describes another type of product, a “Programming System Product” like the operating system he worked on before writing the book. This one costs 9x as much as the program itself.

This should serve as a warning to framework writers: how much more costly is your framework than writing the code? 3x? 9x? Are you sure you will recuperate that investment? Will programmers write their applications 3x faster? 9x?


If you’re interested in developing Wiki2Go, the project is now hosted on Rubyforge


TheMythicalManMonth And read this book!

Theory of Constraints

I’m writing a series of notes on the “Theory of Constraints”, based on the “I’m not a bottleneck! I’m a free man!” sessions at XP2005 and SPA2005.

Why did I get interested in the Theory of Constraints?

  • It gives me a different perspective to look at systems and organisations
  • The Theory of Constraints is very simple. But the conclusions one can draw from it are often wonderfully counter-intuitive, yet very effective
  • It is a complementary tool to “Lean Thinking”: ToC tells you what to optimize, Lean tells you how to optimize. ToC focuses the system optimization effort where it has the most effect.
  • ToC is a whole-system method. Local optimisations often have detrimental global effects. ToC helps me look at the whole system and then take action at the local level (the bottleneck).

Read more about it:

TheGoal ItsNotLuck ThinkingForAChange

Back from XP2005

It’s more than a week since I’ve come back from XP2005 and I’ve just about recuperated. That’s the sign of a good conference: exhausting but rewarding.

Hubert Baumeister has a great series of pictures of the conference

I co-hosted 3 sessions:

Fortunately, there was some time left to attend two great workshops:

  • The Coder’s Dojo workshop by Laurent Bossavit and Emmanuel Gaillot. In this workshop we explored two ideas that the Paris XP group have been experimenting with for the past half year:
    • Coding Kata: a programming task is given and prepared for the next session. During the session, the programmer presents how they arrived at the solution, starting from scratch. The presentation must obey the following rules:
      1. It must be performed in the given time
      2. The programming task must be solved
      3. Everyone in the audience must be able to understand all steps taken
    • Randori: each participant in turn makes the code pass a failing test and then writes a failing test for the next participant. That was a lot of fun! We learned a lot about taking small steps and TDD when the process stalled because we were trying to take too big a step.
  • The Agile Contracts by Mary and Tom Poppendieck where we presented and discussed ways of writing contracts that promote cooperation and work well with Agile software development principles.

There were lots of other interesting workshops I wanted to attend, but unfortunately one can only be in one place at one time… More on those later.

Some interesting keynotes by Jutta Eckstein, Kent Beck and especially John Favaro. More on those later

XP 2005 Keynotes

There were several keynotes at XP2005. Some more interesting than others.

Jutta Eckstein‘s keynote had this simple, but effective message “Agile has come of age. The hype is over. If you’re into hype, nothing to see here, move along while we get down to real work.

Kent Beck‘s keynote was about “Taking it up another notch” and “accountability“.

Accountability is the word on Kent Beck’s mind, these days. We should all take responsibility for our actions and their consequences. Kent gave the example of replacing the well-known XP maxim “Change your organization or change organisation” by “You can only change yourself”.

Taking it up a nother notch does not mean doing the technical stuff with even more fervour. It means expanding our worldview and applying agility to the organisation, the world. Which ties in neatly with the keynote by John Favaro.

Johan Favaro‘s keynote was the most interesting one for me.

One of his points is that:

  • Great IT can improve productivity by 2%
  • Great management can improve productivity by 8%
  • Great management AND IT can improve productivity by 20%

But we so often fail to get that combination right. Why? Business and IT aren’t very good at talking to each other and working together. Business people don’t understand us. We don’t understand business people. IT management is very rarely based on a sound management and financial basis.

This talk was a call to arms: we must learn to talk the business talk. And not only talk the talk, but walk the walk.

In my experience, I find it easier to talk to business people about agile. They love it! They want to be able to steer projects, review and revise plans, they want to make IT decisions on the basis of value and cost, they know how to deal with risk, they understand the value of early delivery…

It’s mostly IT management who resists the change to agile. Why? Because it’s a threat to their cushy jobs, where they don’t seem accountable (here’s that word again), where they know better than the business rabble, spouting meaningless techno-babble to befuddle anyone who wants to examine what they do. Agile means openness, communication, accountability. And some people are afraid of that…