Is / Should What We Do When Building Software Be Called Engineering?

Agility as learning - engineering as the realisation of telos

Other classical forms of engineering are not really working in complex adaptive systems, they are in physical systems.

Whilst we can take scientific method from them, the thing we are measuring and building for will change its behaviour - and we are in the business that should be designing for this. This is very different to say a bridge or tunnel - which are phenomenally complicated things.

eg someone was saying on linked in that ‘you cannot agile to the channel tunnel’.

But that would be insane, instead you use experiments + agility to learn how to build tunnels and how they behave, you measure and prototype and run tests.

Through doing this we convert the complexity of learning how to build a tunnel into a complicated set of rules in a book you can follow to design, cost and build a tunnel.

All the agility is in the learning to enable this conversion. This is the key difference - in software that learning cannot ever stop. In fact when we see a project that has finished learning and has no more changes we call is ‘abandonware’ and are highly distrustful of it.

Building the tunnel is execution after understanding - its a formality when you know it will work. We understand how to take the complicated plan and break that into clear tasks to get there.

This difference is the difference between thinking you can use a map to get out of a maze - and knowing that the walls of the maze will move as you explore. Both of these situations require radically different approaches to solve.

Engineering is a practise of discovering constraints to convert complexity into complication

In software when you build a thing for people - you change the people and so their needs. So the building of the thing, whilst it should be a formality, also represents a new datapoint in learning about the customer. It is the start of a cycle, not the end.

We cannot convert people into complicated systems - by the very nature of what a human is, people systems are complex adaptive.

So the thing we build is part of a cybernetic system, a system of people connected via technology acting as systems in system. This means we cannot abstract away from the people using it - that would remove the temporal aspect.

So the majority of our engineering effort should not be directed at the ‘thing’ artifact. It is the system that produces, learns and changes the thing because the architecture and structure of the thing should not make sense without that context. This is where team topologies does not go far enough imo - but Skelton put some names to things previously unnamed which was very helpful and way ahead of the curve. The next higher abstraction will be about naming coupling and cohesion at a higher level.

Its too easy to get distracted by the tunnel.

The code has very little value in itself - and runs on billions of lines of instructions that we don’t think about. We don’t think about anything to do with bare metal anymore - eg temperature and airflow. So arguments about ‘software engineering not being abstracted enough to be called engineering yet’ are just a slippery switching of context. It will become ever more abstracted, and the same objections will exist.

We don’t do engineering - well we might do partially - but that misses the vast majority of what we should be solving for.

So when we call software development ‘engineering’, we are talking an abstraction from one place and applying it in a place it won’t fit - or would be dangerously reductionist and miss some of the more fascinating problems.

Namley ‘why do we live in a world where we think we can seperate software architecture from team structures, and why do we think we can seperate team structures from customers?’ - when you think of these things together, then the sequential flows that we are obsessed with start to seem very cult like and purile. The systems we are engineering are far greater than code and the craft of code organisation is incredibly well suited to debugging these more abstract problems - because at the end of the day mapping flow is all we do.