Ode to software

Software, like all technologies, is a kludge. It's a clumsy, inelegant, and jerry-built contraption that sort of works, some of the time.

Stewart Brand, The Clock of Long Now

Marc Andreessen wrote software is eating the world a dozen years ago. And then it did. To the point where the largest companies in the world are undeniably software giants. Even Apple, which makes and sells beautiful hardware, has as one of its major selling points the incredible software that they produce.

Software is also incredibly complex. Far more so than anything tangible we produce. The great Cheops pyramid took around a decade and half with a peak workforce of 40k workers, maybe 1 billion man hours. Parthenon around 36 million. The Colosseum maybe 100 million, same as Notre Dame, that gorgeous cathedral.

However, Facebook, how many man hours do you think that took? It’s the same app, there are some percentage of employees who helped actually write the software, and this changed across the company’s life, and yes there are rewrites but the rewrites are part of how you learn what you should have written in the first place. And there’s a hell of a lot of maintenance, and continuous development, because both the product and the very environment it’s created it constantly changes. The rather crazy answer is that it probably took close to 200 million man hours. Even Uber is close to a hundred million. Microsoft? Partly because of the number of iterations, probably it’s a billion by now!

It’s an achievement on par with the pyramids of Giza. Actually, more, in its necessity to keep running to stand still! Creating software is some of the most work we’ve put into building almost anything, far beyond the wonders in Rome or Luxor. The International Space Station probably still leads, at around 6 billion man hours, but man, its getting close.

That’s what it means to live in the Information Age. The things we build might not be as easily visible but they are the water we swim in.

We knew what the pyramid would be when we started building it. The actual act of creation was not also simultaneously a journey of discovery. This is not the case in software. Is the time for Facebook's current application the correct consideration, or is it all the time we spent learning what to build and building underlying infrastructure part of it? Maybe one and not the other? Technical debt isn’t debt, it’s the commit history of the decisions made in the past. The flip side is that a pristine codebase could only ever be a dream.

Though that still understates things. The things we’re making with software are far more intricate, interlinked to other pieces of software and hardware and user input and more, than any we’ve created before. The complexity of a piece of code can be equivalent to the complexity of an entire culture, in its myriad dependencies and the long tail of knowledge that’s needed to truly understand it.

For instance, this is the dependency graph for tensorflow, streamlit and scikit-learn. In case you were planning on doing some ML work this is what you pull in to help bring that collective expertise into whatever you want to build next.

Or this, which is the dependency graph for PyTorch in apparently its full glory! It bundles 40+ dependencies, which often have dependencies of their own (and what’s shown below is distance 2 or less).

Software is still very new. It basically came into being as its own thing when IBM split it's System 360 division of only 4,000 people, barely 3% of their workforce, into a separate division from hardware, to build a truly modular computer¹. Since then it’s become almost a shorthand for technology itself. To work with information feels, after all, easier than working with physical things, even though building it is more complicated.

And what gets built rarely stays built. There was a while where everyone thought investing in software was the easiest way to make money, because they got seduced by the gross margin (selling an additional unit of software is extremely cheap). But the implicit depreciation in software is incredibly high! You have to run extremely fast all the time, or you get beaten. As Bill Gates said:

In three years, every product my company makes will be obsolete. The only question is whether we will make them obsolete or somebody else will.

This also means that software is meant to continually change. Not just because we keep finding new technologies to use, but because each step along the way we figure out new things to add and change and amend and continually make it better.

Of course, this isn’t the only comparison. Because comparing physical structures isn’t exactly analogous to the more nebulous structures of building software.

Here we can look at other such nebulous structures that we do build, like cultures or organisations. Building them is an ongoing process that can span generations. It involves not only the initial establishment but continuous investment in maintenance and growth.

Empires, cultures, cities. They're similar. They’re path dependent, built on top of what came before, constantly evolving. And they require incredible effort to build and sustain.

If software is “softer” it’s only because that’s a function of iteratively building solutions and then dealing with the problems that resulted from building things, basically sounds a lot like running an organisation.

Looked at this way you might think the Roman empire might have seen over half a trillion man hours dedicated to its maintenance. Egypt, which lasted longer, might have been as much as 2-3x more than that. However, only a tiny fraction of that was in actively building up a superstructure atop which it could grow.

What about the British Empire? More people, almost 400 million at its height, so much more administration. And though once again only a fraction actively involved in its development, it would exceed the same magnitude as the Romans, surely.

We can look at other crowning achievements. The Manhattan Project had around 130,000 people working intensively over 4 years, which is well over 1 billion man-hours. Or just look at the history of IBM, which has been alive for more than a century, and has surely dedicated more than 200 billion man-hours in its life so far.

When you think about what British Empire did, or the Manhattan Project did, or god forbid what IBM did, what they actually built was not a ‘thing’ like the Pyramids or even the ISS, but instead an an organisation, one greater than the sum of its parts. The decisions that made them sometimes lasts through the ages, but mostly the outcome stands apart from the decisions that made them. And even they aren’t composed of the decisions the same way we build code on top of code.

For that, as also for the empire, the man-hours metric by itself is insufficient. Because while it shows the effort that went into making what we see today, it doesn’t distinguish between efforts that were wasted or misdirected and those which was necessary in getting to the current path.

Anyway, the organisations we create are built on top of a large numbers of decisions, made by thousands of people, built up through explicit rules and implicit culture. It’s a singular entity, but not one easily reducible to its constituent building blocks. Building Facebook is closer to a constant series of management decisions than the painstaking labour of piling stones up high.

And since software is the record of those decisions, built on top of older decisions, enough that a codebase is closer to a history of the decisions that the people building it made, this makes software just like organisations, a form of congealed ideas that we get to reuse, so we don’t have to redo them. The fact we can reuse them is the new part. There exists parallels, like laws or regulatory code, where we build on top of what came before. But even more than that, software takes codifying decisions and standing on top of them to a whole new level - just look at the intricate linkage charts above.

Understanding software as a form of codified management decisions gives us also a different lens on how to think about the things we couldn’t quite fathom before. It’s not a “thing” like the Colosseum, nor is it art, nor is it science. It’s a history of small lego blocks of problems solved that, if you work hard enough, you can stack up too in order to do harder things.

We don’t see this with other arenas much, but we do see this all the time in academia or management, where ideas aren’t the end point, they’re the substrate.

It’s also why software has a much larger stack of “open source”, where you create some of these lego blocks as both a show of talent and a contribution, because popularising the things you’ve built is the best way to ensure they’re widely adopted. And once they’re adopted they can get reused. This is also why large companies are quite often the largest contributors to Open Source. Because building the tools that helps set standards (or raise them) helps them build better software².

In the old book by Mark Twain, A Connecticut Yankee In King Arthur’s Court, Hank Morgan tries to use his knowledge of modern technology to make medieval society where he ended up better. And turns out it’s not straightforward, because so much of what we consider the incredible benefits are built on top of what came before.

So if software is essentially a form of congealed decisions, then it’s not a product, it’s a process. There is no idea of a perfect product, because there is no perfect thought, the point at which you just stop thinking or when you’re done. And we live in the middle of the Eternal Refactor. That’s what software eating the world actually means. A new information supralayer on top of everything else we do³.

That’s the magic of software. It makes historic decisions part of the legible firmament, even as it remains the most fleeting ephemeral medium we’ve devised, because decisions change and morph all the time.

It creates entire in silico civilisations with its history writ within its fundament.

Software is ephemeral because what we want is ephemeral. We find new ways of doing things, and it changes. The half life of software is short, and even the mightiest builds have to be rebuilt soon. It's the red queen's race. You are unable often to see the wonder in the blueprints, but only in the execution. When enormous levels of depreciation is price then then the only way to judge continuing success is to bet on the ability to create beauty on an ongoing basis.

(If you are at all intrigued by this you should read the upcoming book by my friend

Samuel Arbesman

on the wonders and weirdness of computation, follow along here!)

It’s not the ingredients or the recipe that’s most important in software, but the chef and the preparation. It’s the speed of creation. You don’t win by creating the Pyramid, you win by creating something as splendorous as the pyramids, faster. And then again! The ability to make things is the core value, not having made a valuable thing. Craftsmanship is the goal, not the craft itself.

We will continue to see the Pyramids as a height of human achievement through the next millennium. Shakespeare will stand the test of time. Einsteins theories will never lose their magnificent intellectual splendour. We remember the scientific discoveries and the story of a serpent swallowing its tail as the metaphor for benzene or Einstein’s magnificent thought experiment about standing on top of a light beam traveling as an elevator. We even will honour the decisions taken in history, Napoleon’s defeat in Waterloo by the Duke of Wellington or Churchill’s decisions in World War II or even the business decisions by Andy Grove or Rothschild or J P Morgan.

Code though, code won’t stand the test of time. Nobody will be praising the beauty of the code that sent the first man to walk on the moon, or the code that enabled a 100 billion messages to be sent between all of us, daily. Once writ down and made concrete it becomes invisible. We use it like disposable bricks that make up an edifice.

Facebook might be a cultural artefact but Facebook code is not. Like a coral reef, it remains the invisible graveyard of millions of decisions taken without elevating any single one. You are able to enjoy Shakespeare's king Lear without needing to also understand its cultural context or his writing patterns and methods, you are able to enjoy the pyramid without needing to dive deeper into the intricacies of the Pharaoh system. But with technology just like with culture or civilizations it is only the cultural context and product that gets any kind of immortality and all the effort that goes into producing it vanishes like so much mist in the morning.

But maybe we ought to pay a bit of attention to its lifecycle. It has a half-life, but that only makes its production function more important. To understand it a bit better. To incorporate its love of ephemerality into our collective understanding. To enjoy the craftsmanship and to separate that from the product itself. To reduce the pure commodification of its power⁴. It does, after all, make the entire world go round.

1. You could go back to Ada Lovelace and make an argument there, but it would be little different from working on algorithms, and that really isn’t what we’re talking about here

2. And helps in bringing the most ambitious people to come work for you too, those who are exhilarated by the idea of building something new.

3. Have you noticed internet arguments about new policies that are proposed? “This is not what was originally intended”. “Last time this was done in [X] situation bad things happened”. The belief is that if we could see these decisions around us, created and codified and maintained in like a network, then we could make much smarter decisions going forward.

4. Which seems the case, even when you take the biggest VCs or technologists, who often talk about a product made from a pile of code as if its inert.