Why Now? The Great Software Misunderstanding

I've become slightly obsessed over the last couple of years with constraints, in the way you become obsessed with something once you've noticed a pattern and then start seeing it everywhere. If you wanted to manufacture cars, you needed factories. If you wanted to publish a newspaper, you needed printing presses. Making films meant cameras, studios and distribution networks. The people who controlled those resources had a considerable say in what was possible.

Then, every so often, something strange happens. The economics change. Desktop publishing arrived and suddenly publishing wasn't only for publishers. Digital cameras arrived and photography wasn't only for photographers. The internet arrived and retail wasn't only for retailers. Smartphones turned technologies that previously filled rooms into something we carried in our pockets. Looking back, the winners of those transitions weren't always the people with the most money, the biggest companies or the strongest market positions. They were often the people who recognised, sometimes before everyone else, that the rules had changed.

I believe we're living through another shift in what becomes possible, although the part that interests me is less spectacular than the headlines. Artificial intelligence can write code, create images and answer questions. I use those things every day. What has changed my working life is the cost of turning an understood problem into something I can put in front of the person experiencing it.

For most of my career, software was expensive to create, as well as sometimes being expensive to buy. Matching it to how your business operated could mean analysts, architects, developers, testers, project managers and infrastructure. It also meant time, often months or years, by which point the original problem had usually acquired several new friends.

That economic reality shaped the way organisations thought. Businesses learned to compromise. They changed their processes. They adjusted their expectations. They accepted inefficiency because removing it was simply too expensive. Restaurants changed how they operated because the software couldn't change. Garages adapted their workflows because the software couldn't change. Hospitality operators built spreadsheets beside systems because the reports they needed didn't exist and creating them would cost too much.

Eventually, something remarkable happened. We stopped seeing this as a compromise. We started seeing it as normal. In fact, entire industries emerged to help organisations manage that compromise. Consultants, implementation partners, system integrators and transformation programmes all existed, in one way or another, to solve the same fundamental problem, software was expensive to change.

But what if that equation changes? That's the question I haven't been able to stop thinking about. Because somewhere over the last few years, without much fanfare, the economics of software creation began to shift. Not a little. Fundamentally. The cost and effort required to turn an understood problem into working software has fallen dramatically. Almost everything interesting in this book begins there. Because if creating software becomes dramatically cheaper, then all the assumptions built on top of expensive software suddenly become questionable.

Why should a business adapt itself to software? Why should somebody spend an hour every day re-keying information because a system can't change? Why should operational knowledge live in spreadsheets, notebooks and the heads of experienced people? Why should organisations continue paying the hidden tax of friction simply because that's how things have always been done? For most of our careers, the answer to those questions has been the same. Because changing the software costs too much.

At first, I thought the interesting thing was building software quickly, then cheaply. Eventually I became more interested in what deserved to be built. Understanding the work has always mattered, of course. I have not discovered listening. But when a possible answer can be created much more easily, the quality of that understanding becomes harder to hide behind the cost of implementation. Secure integrations, testing, support and reliability still take serious work. What has changed is that, for many smaller problems, I can now afford to find out whether an idea deserves that work before committing to all of it.

And once you start looking at organisations through that lens, you begin to notice things that were previously invisible. The spreadsheet sitting beside the system. The daily apology that nobody hears anymore. The weekly meeting that exists because nobody trusts the report. The process everyone agrees is ridiculous but nobody has challenged in years. The experienced employee who keeps everything functioning because they've memorised all the exceptions. These aren't failures. They're adaptations. Evidence of intelligent people working around constraints they inherited.

Which brings me back to the observation that started all of this for me. For decades, we've assumed that businesses should adapt themselves to software because software was too expensive to adapt itself to businesses. Maybe that was true. I just don't think it's as true anymore. And if that assumption is weakening, then the question becomes very simple. If software can increasingly adapt to the business, why are businesses still adapting to software? Everything that follows in this book begins with that question.