6. Gall’s Law

One of my favourite laws – one of those principles that seem to be universally applicable – is Gall’s Law. People who have worked with me in the past are probably very tired of hearing about it.

John Gall was an author, scholar and researcher who focused on systems and systems theory, and he wrote a very famous book called Systemantics back in 1975 – it’s been updated, it’s available today as the Systems Bible.

The Systems Bible is, on the whole, absolutely brilliant.

I recommend it.

Everybody who works in software should read it and be filled with despair. Because it will fill you with despair. You will recognise everything written in this text from 1975, to your horror.

One of the most long-lived and popular – or infamous, if you’re so inclined – adages or rules from his book is what’s been coined Gall’s Law. It goes as follows:

A complex system that works is invariably found to have evolved from a simple system that worked.

A complex system designed from scratch never works and cannot be patched up to make it work.

You have to start over with a working, simple system.

Systemantics

In my experience, this is a universal rule.

I have never seen anybody manage to break John Gall’s Law. It applies to every single aspect of software development, in that we are fond of planning and organising and building complex systems from scratch. We design these intricate structures of objects and classes that interact. We build things that have no chance ever of working.

Instead, the alternative that I always advocate is to try to bake evolution into your design. It’s fine to have a complex system design that you’re aiming for in the long term, but you need to have a clear idea of how it will evolve from a simple system that works to a complex system that works.

You cannot leap straight into the complex system.

You have to start small.

This applies to every system and subsystem in a software development project, whether it’s a feature or a module or the app itself.

Start with a single system, simple one that works, then you evolve and add to it. If you’re adding a new feature, then it has to be a simple, single thing that works from the beginning, and then you build from there.

If you’re making an app, make a simple, bare bones, flawed but working app. It can be flawed in that parts of it are obviously missing.

It can be flawed in that it’s ugly.

But the systematic aspect of it, the code, that needs to be working, and it needs to be simple.

This is the only way to make working software, but it’s also a rarity. It’s the exception. I have almost never been able to convince a manager that we should do it.

I’ve convinced them that they should do this, but they’ve never actually accepted it in practice.

They say, yeah, absolutely.

I believe in a minimum viable product.

But then they keep adding things to what constitutes the minimum, and they don’t realise that MVP is not the simple system that John Gall is talking about.

The simple system does not have to be shipped.

It just has to exist as the foundation that you build on. But they don’t really get that when they’re managing the project.

In the story, feature, or point breakdowns I’ve seen, it’s clear they don’t understand the systematic aspect of it.

They almost always start with this vision of a complex interlocking thing we’re just colouring in the numbers for.

They don’t grow the system.

They don’t grow the software.

There are exceptions, and those are great projects and great places to work in.

But all too often, there’s a fundamental misunderstanding of how a software system works on the part of the managers or the executives of the projects that I’ve worked on.

I suspect that the same applies to everybody who’s listening to this.