Software is in the current industrial revolution oft compared to the factories of the first one.

The first factories took electricity and put tools and processes in place to put that sparky, ethereal juice to work to enhance the productivity of the worker.

And so it shall be in software. Software shall be the factory. Right?

Software defines, operates, manages and reports on the processes & flows of putting data to work to enhance the output of people in our rapidly dematerialising world like a factory did to raw materials before.

Of course, that analogy is a simplification, but it is a compelling parallel.

Well designed, well-operated factories and the processes that made them tick allowed organisations to deliver productivity gains that traditional methods – and less well-conceived factories – couldn’t match. Similarly, flexible, well architected and appropriately executed software does the same for organisations today.

Important lessons can also be learnt from the management and evolution of factories and applied to software, although they’ve often been overlooked. Successful manufacturing paradigms such as Lean Manufacturing are transposed to software development and the concepts of “never being done”“there’s always room for improvement” – can be applied to the approach we take, the expectations we set, and the results we achieve in software development.

But, as with all successful evolutionary steps – you keep what works and adapt what doesn’t.

The traditional “Design & Build” approach of physical factory construction has often been mirrored in the regimented “waterfall” model of software development. The Waterfall model focuses on up-front defining, designing, & documenting every last detail of a piece of software and committing to large, long-running programmes to build it. This has been fraught with problems, including, but not limited to:

  • The process takes so long the need has changed by the time the product arrives
  • The things you think are important and invest significant resource in turn out to be something the market, your customers, and your users don’t care about
  • You end up with an “all or nothing” deliverable – either we finish the project, sinking yet more cost, or we scrap the whole thing – often leading to black hole projects sucking in more and more resource that nobody can afford to call time on (who wants to write off all that sunk cost?!), but never quite get to the finishing line

Thankfully we are discovering and learning improvements and evolutions over the factory approach to reduce some of these risks.

Taking lessons from previous transformative revolutions and applying a more positive view of people and collaboration as sources of opportunity (rather than a ‘resource’ to be micro-managed and tied up in bureaucratic specificity) and applying them to software has lead to an alternative way of thinking about software development – the Agile approach.

Agile software development isn’t exactly new – the meeting of self-proclaimed organisational anarchists that spawned the Manifesto for Agile Software Development happened in a Ski Resort in Utah in 2001[1] – and the word Agile is perhaps one of the most used and abused terms in technology today (AI may be another candidate for the #1 spot for abused terms).

For those of you not familiar with the Agile Manifesto I outline (shamelessly plagiarise) it here:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

 That is, while there is value in the items on the right, we value the items on the left more.”

Delivering in an agile way isn’t free of its own challenges. One key area of change is procurement. A traditional budgeting and procurement approach, for example, likes to button down exactly what the deliverable you’re buying looks like, what it does, what it costs, and when it will arrive.

These are all things that can change along the way in a genuinely agile project – because change is how the real world works. But getting buy-in for an agile approach can be a challenge, largely because it’s unfamiliar to many and occasionally because many people’s experience has been of processes masquerading as Agile.

The successful application of the Agile approach however, when truly embraced and embedded into not just the software development team, but into product & service delivery teams, procurement, and ultimately into to the culture of an organisation can have a fundamental impact on the cadence with which products (software and physical products too), can evolve, deliver value early, improve, respond to ever changing demands, and rapidly unlock the value of the raw materials an organisation has available – it’s data, its customers, its products, and most importantly its people.

Software may have parallels to the first industrial revolution but done right it can empower so much more.