Monthly Archives: January 2014

It’s the process, not the product

Stuart Boardman retweeted a link to a blog post by Rob Vens: “Software is not a product“.

In this post, Rob argues that we ought to consider our (hopefully ever improving) process of creating software as the primary product of our work rather than the software itself. In this sense, he argues that software is only a by-product of our work.

Interesting. I exchanged a few more tweets with Stuart in which he observed that “product” does not mean (physical) “good”. Indeed, services are products, too, both in a general sense and in the context of Rob’s blog post.

In my experience, clients still want to buy the results of the software process (e.g. an evolving web shop) rather than the collaborative design process yielding this result. This is despite the fact that software development processes and methods can be the subject of great debate at all phases of the sales and delivery process.

But herein might lie great opportunity: What if we could shift the conversation away from that by-product of our work to that collaborative design process that creates that seemingly auto-evolving web shop?

And maybe there is a chance of actually making this happen, if Laura Colvine (via Jeff Sussna and James Rock) is to believed: “It’s H2H: Human to Human“. (Alright, so I’m quoting this out of context.)

I’m well aware that the above is a tiny step for humankind, but it has been a greater and very enjoyable one for this human. Thank you to all of you who contributed to it.

I know realise that “The process is the product” would have been a better name for this post.

Use cases in lean architecture

James Coplien and Gertrud Bjørnvig have written a wonderful book explaining how lean architecture can play a meaningful role in agile software development. Here they describe the benefits of use cases “as a way to capture what the system does when it is important to understand a sequence of work towards a goal in a context” (Lean architecture for agile software development, ch. 8.2).

The notion of a sequence of work towards a goal in a context resonates strongly with me: it’s a brief and–to  me–powerful way of tying what needs to be done to context and purpose.

I have been working on e-commerce sites for the last few years. Much of the work has been driven by conversations about user journeys or user interaction flows (or whatever you’d like to call this).

I suspect that interaction flow descriptions/visualizations and use cases might well complement each other, but I haven’t yet seen them being effectively used together. I’d be grateful for your thoughts, experiences and suggestions.


When I say “use cases” I refer to the Alistair Cockburn tradition.

James & Gertrud more often used the phrase “a sequence of tasks…” than “a sequence of work…”. The latter seems preferable to me as it seems applicable in a much wider context.