Commoditisation, Or Lack Thereof

Commoditisation, Or Lack Thereof
Munich, Germany

This is the part where the rubber hits the road.

There are two famous big-picture analogies that I've seen used to describe software development. First, a story of incremental improvement where the delivery of a bike precedes the delivery of a car which is followed by the delivery of a plane - it is less about modes of transport and more about shaping the value curve away from something that spends a lot of time at zero with a large peak and into something that is more stable in time. Secondly, a story of software as construction. Preparing the site, laying a steady foundation, and eventually there is a handover. These two analogies have something in common. They lean very heavily on commoditised products. Blocks of timber, steel beams, copper wire, houses, skyscrapers, bikes, cars and planes are commodities that require no explanation to most people. The great limitation of these popular big-picture analogies is that they fail to communicate the absence of such commodities.

What would it look like if we were building something without commodities or their production processes? It would look like the Apollo 11 mission. It would look like the Manhattan Project. Groups of highly skilled professionals applying the knowledge that they have on a semi-speculative basis, in competition with other groups of highly skilled professionals around the world. If I was given the opportunity to beam one and only one message across the world, at the moment it would be this:

Many software projects have much more in common with the Manhattan Project than they do with the construction of a residential home.

In my last post, I introduced divisions of labour, and in the one before that, an introduction to code and quality metrics, which spelled out that the production of code (i.e. the work that software developers actually do) is distinct from the customer value, the digital experiences that users consume. What is not explicit but emergent from the various concepts introduced in my previous posts is that although you may commodify a digital experience (e.g. apps A, B and C have feature X) the path to building that digital experience is not necessarily commodified. For all but the most trivial of software applications if you were to assign the same brief to 100 teams of software developers you will obtain 100 code bases with different technology choices, different divisions of labour, different performance along both quality metric and project success metric (cost and time) lines, among other things.

This communication project will continue, there is still so much to talk about. The Factory. Education. Recruitment. Recognition (and resentment). More to come.