• “The rework required by past choices” is an inadequate definition of tech debt.

• It is inadequate because it is overly focused on litigating the past decisions of others and neglects the (much greater) amount of rework required by changes in the world that don’t stem from previous choices made by system designers.

Part three was about how software systems fall apart just like everything else. Financial accounting has a way to track the loss of value from stuff falling apart called depreciation.

When your business plunks down some money to buy a new piece of equipment, your accounting department does not immediately classify it as an expense (a decrease in your assets). It’s true you have less in your bank account, but now you have that shiny new piece of awesome. You transformed one asset (cold, hard cash) into another (a cool doomahickey you are going to run part of your business with).

But your accounting team is well aware that things fall apart and so, every year, they will depreciate the doomahickey by reducing the value of it on the books and adding an expense of the same amount it was reduced. After a somewhat arbitrarily chosen period, the doomahickey’s value will be zero, at least as far as your accounting department is concerned.

Which is just fine – everything does fall apart so why shouldn’t the rules of accounting reflect that? Depreciation is just the accounting profession’s nod to the Second Law of Thermodynamics, which comes for us all, even doomahickeys.

So what, exactly, is the problem?

If we can account for things falling apart, then is tech debt an illusion?

If you buy your kid a new car, it will lose value over time, starting as soon as it’s driven off the lot. But you don’t owe your kid a new car just because you bought them one years ago and it is now worth a lot less. You both knew that was going to happen when you bought it. Such is life and cars, kiddo.

So is tech debt just a verbal tic that whiny engineers trot out for stuff they don’t like? I do not think so. Recall from Part three that complex systems fall apart in three ways:

1. The solution system decays.

2. The problem system decays.

3. The coherence between the solution and the problem decays.

The rules of depreciation focus on the first kind of decay (since those rules are about the value of the solution system as an asset that you own), and that makes sense because those rules were designed for physical equipment, which tends to wear out before the world it is used in changes enough to matter.

But software decay is dominated by changes in the world and organizations struggle to “see” the decay that is happening to solutions which appear to more or less work the same as they always have1.

Consider the Southwest Airlines holiday travel meltdown. This extended and widespread disruption in Southwest’s operations was ultimately deemed to be the result of long-obsolete software, a fact clearly known by some at the airline, but possibly not known by leadership. At least I suspect leadership did not realize just how badly out of date the system was as it led to an enormous loss of money and customer goodwill on top of the money they have to spend to upgrade, and it was a priori likely to do so if you knew the sorry state of the software.

Southwest’s software was so out of date one might ponder whether its value was literally negative. I am guessing their financial statements did not have a liability for “critical software that has decayed to the point where our entire operations are one bad weather day away from an embarrassing and expensive total system failure".

Some people who almost certainly did not know that was the state of affairs were the travelers who bought Southwest Airlines tickets right before the meltdown. And Southwest’s shareholders were probably a bit surprised too.

Tech Debt as a missing accounting entry

Southwest pledged $1.3 billion in software maintenance and upgrades in the wake of that disaster.

When you pay for a service, there is a basic presumption that it is fit for purpose, that it actually provides an acceptably working version of the thing it is nominally offering. As it turned out, Southwest’s service was not fit for purpose and it’s costing them $1.3b to remedy that. I think it is entirely fair to say that, prior to the meltdown, there was a $1.3b hole in Southwest’s books that the world only became generally aware of after the fact.

Let’s suppose that Southwest had let the maintenance of its planes languish to the point where the paint was falling off, the interiors were dirty and frayed, etc. This would also represent a loss of value, but everyone would already have known that – travelers could just see it with their own eyes and would quickly decide to stop flying Southwest!

The key point of Part 3 is that while software systems fall apart like everything else, the way they fall apart is distinct from the way that physical equipment wears out. Software systems mostly decay by gradually losing coherence with the world they are meant to inhabit, and that makes it much harder to notice that it is happening.

This brings us back to my original claim in Part 1, where I unpacked the debt metaphor and concluded there had to be two parties involved in tech debt and one of them was probably the customer. Now I am in a position to explain what I think tech debt is and how it comes into being:

1. A software solution is created to solve a problem, creating something of value where the value is the worth of solving that problem.

2. Over time, the coherence of the solution / problem system decays, thus making the current solution less valuable than when it was created. The software solution may even have become a net liability because the coherence has decayed so much.

3. Because of the way that decay happens, the total extent of the loss of value is not widely known, particularly to customers and shareholders, but also within the organization that created the solution.

4. The technical debt in the system is the unacknowledged, unaccounted for difference in the actual current value of the solution and its assumed value.

The assumed value is what you would pay for a fit-for-purpose solution to the current problem. And the assumption arises because (most) people have failed to notice how far the current solution and current problem have drifted apart and thus treat the current solution as equally fit for purpose as when it was created.

Southwest’s systems were probably pretty good when Southwest first got going. At least, they could cope with the scale of the problem that early Southwest had. But as Southwest’s routes and hubs got big and complex, the software did not keep pace.

That happened gradually and, thus, was easy to miss if you weren’t working with those systems as part of Southwest’s operations teams. The mismatch between the solution system and the problem system grew to the point where a catastrophic breakdown was just a matter of time.

Sometimes whiny engineers have a point

Although I don’t agree with the current public definition of technical debt, it should be clear I think technical debt is very, very real. When engineers talk about tech debt, and worry about tech debt, I think they have (often correctly) intuited that the organization has failed to realize (or at least publicly acknowledge) how much value its technology solutions have lost and how much liability has accrued because of that failure.

Tech debt is an engineer’s way of saying “hey, we have a real problem building up here and you don’t seem to realize that!” to leadership. The essence of the message, what technical debt is, and my solution to the way we should understand the debt metaphor is this:

And the company owes that value because its customers and shareholders reasonably assume it is there. Maybe it used to be. But it is not there anymore. Sad!

Introducing The Crumble

The economist J.K. Galbraith defined “the bezzle” as the total quantity of undiscovered embezzlement in the economy. During periods with high levels of fraud, there is a net increase in psychic wealth as the fraudsters know they got what they wanted while the marks believe they got something too.

Charlie Munger, late of Berkshire Hathaway, expanded the bezzle2 to include any difference between the actual and reported values of all the assets in an economy, whether or not that difference was the result of fraud. His point being that the existence of that difference was relevant regardless of its cause because of its implications for the future (because one day the difference would be noticed, with consequences to follow).

In that spirit, let’s define the total amount of technical debt in the world as the crumble3. The crumble is that portion of the bezzle (Munger’s expanded version) that is the difference between the assumed value of all extant technical solutions and their actual value, a difference that has arisen because those systems have crumbled away over time as the solutions and their problems have drifted further and further apart while people failed to notice this happening.

Mostly failed to notice, that is. That “tech debt” is so ubiquitous a metaphor tells me that, like fraud, there are almost always people (aside from the fraudster) who know that something isn’t quite right, but they struggle to warn others before it’s too late. Whether “tech debt” as a term of art is actually helpful in that regard is a topic for another post.

Given that Southwest is just one example, I suspect the value of the crumble may be quite large…

The End, or at least I’m stopping for a while

Thanks for reading this far. I think I’ve managed to write a lot of what I wanted to say about technical debt. It’s possible I’ve spent too much time thinking about it. Because I’ll probably have more to say in the future!

If you have found value in reading this, even if as a useful counterpoint to your own, different opinions about tech debt, I’d appreciate hearing from you. In the meantime, here’s a very good boy to whom I owe some technical treat debt:

Peace.

This is Part Three and it’s about air conditioners. So buckle up, buttercups.

Air Conditioners Mostly Don’t Work

Consider the humble air conditioner, humming away making this grass field cooler:

Oh, except it’s not making that grass field cooler because:

• The air conditioner isn’t plugged into a source of power so it can’t function at all.

• Even if it was plugged in, it can’t make the field cooler because the heat generated by the air conditioner is going into the same undifferentiated space as the cooler air and air conditioners always generate more heat than they remove. That’s the Second Law of Thermodynamics which is also known, by me, as Carnot’s Revenge. And now by you, dear reader.

An air conditioner is a complex system that is also a solution to a problem, the problem of making a part of the universe cooler than the parts it is next to. But for an air conditioner to actually be a solution to that problem, the air conditioner has to be hooked up to the universe in some very particular ways:

• The power input of the air conditioner has to be connected to a source of power with the right voltage, frequency, etc.

• The air intake has to be connected to a source of the right sort of air.

• The cooler air output has to be connected to a part of the universe that is relatively sealed off from the other parts, including the air intake.

You can come up with a bunch of other conditions that have to prevail for an air conditioner to actually condition the air in a space, including temperature ranges, humidity, etc. The vast majority of arrangements of atoms to which one might try to hook up an air conditioner will result in the air conditioner failing to fulfill the function for which it was designed.

Here’s a highly unlikely arrangement of atoms where things will probably work out:

But this homeowner is going to run into problems:

The air conditioner might be in mint condition, powered up, and ready to go. No matter, it will be the little air conditioner that couldn’t because the house it’s attached to isn’t structured so as to be air conditionable. Maybe when the house was first built, everything worked fine. Then over time, the homeowner put all their resources into keeping the air conditioner in excellent working condition, while letting the house fall into ruin.

OK, seems unlikely! What if the homeowner just kept expanding the house while keeping the air conditioner the same. Poor little air conditioner! It might be in perfect working order, but no matter, the house is now just too big for the AC to cool the whole thing.

Complex systems like air conditioners are solutions to very specific complex problems in the world. In other words, the solution, the problem, and their coherence with each other are low-entropy states.

Low-entropy states tend to decay into high-entropy messes. An air conditioner hooked up to a house will eventually stop working if:

• The air conditioner falls apart.

• The house falls apart.

• The house changes such that the air conditioner no longer suffices for the needs of the house.

The third point may not seem like decay, but we can view it as a decay in the coherence between the solution system and the problem system, coherence that is needed for the solution to actually work. Any random change in either the solution or the problem is likely to reduce the coherence and thus reduce the effectiveness of the solution.

Please talk about software now

Software solutions are complex systems and thus subject to entropic decay. Software code is an unchanging virtual artifact, like mathematics. But code isn’t a solution any more than a blueprint is a house. Turning code into a working system requires instantiating it on a physical substrate that interfaces with the world in the particular ways required by the solution. And just like the air conditioner / house system, that specific instantiation will, absent sufficient inputs of energy and effort, degrade over time, becoming a worse and worse solution until, one day, it just stops working at all.

Sad! It is helpful to consider how software systems, in particular, decay over time. Most directly, the equipment upon which the software is running are physical systems that will age and eventually fail. This is normal physical asset depreciation.

But even though code itself is unchanging, specific code as a good solution can decay. Consider the prevalence of obsolete languages, tools, and dependencies. When you started writing that shiny new greenfield solution, of course you picked a new version of a well-supported language, the latest versions of tools and libraries, etc. So hot!

And now, years later, those exact same versions of languages, tools, and libraries are embarrassingly out of date, increasingly unsupported, and riddled with subsequently discovered security vulnerabilities. A part of the house decayed while you were focused on the air conditioner.

Or now your database, which worked so well when there were hundreds of records, struggles with millions or billions of records. The house got bigger, the air conditioner stayed the same.

That decay just happened, because the world changed, and will keep changing, and every change includes the possibility that your solution gets further out of coherence with your problem. That’s life. That’s Carnot’s Revenge.

The bankruptcy of debt as past decisions

And now hopefully it is clear why I think “tech debt is the cost of past decisions” fails to capture the true nature and scope of the problem. Over time, the explicit changes we make are nowhere near a comprehensive account of the total changes to the solution/problem system, the rest of which happened independently of our decision-making and likely caused the problem and its solution to decohere.

In the next part of this series I will discuss alternate ways of defining technical debt, by moving from the exciting world of air conditioning to the thrilling world of financial accounting. In the meantime, here is a possibly not historical picture of the bad-ass Nicolas Carnot:

And here is a very good boy just minding his own business, not decohering anything:

May your day be as peaceful.

Stu to the rescue?

Let’s imagine an alternative universe that is identical to that scenario in every way, except instead of Sally we have Software Engineer Stu. Unlike Sally, Stu is a new engineer, it’s his first month on his first job. Stu needs to implement the same feature as Sally, but Stu doesn’t know about the Somehow Better Way. Stu is new! We can’t expect him to know every design alternative under the sun.

When Stu fires up his IDE and consults a coding copilot tries his best to figure out a solution, the Quick and Dirty Way is the one he lands on, except Stu doesn’t see it as the Quick and Dirty Way. As far as Stu is concerned, it’s a Perfectly Good Way That Works Just Fine. It’s probably similar to the way the existing code already works.

Stu implements exactly the same feature as Sally in exactly the same way, except Stu isn’t choosing expediency over robustness. Stu just writes what he sees as a good working solution and calls it a day.

If tech debt requires a choice, then Stu has managed to avoid creating any tech debt at all. Nice work Stu.

This doesn’t seem quite right

The two systems managed by Sally and Stu are identical, but only Sally created some tech debt because Sally knew more than Stu did when she made her fateful choice. But if Sally’s system is going to require some rework in the future, surely Stu’s will too. This illustrates what I think is a serious weakness in the definition of tech debt – it depends too much on the psychological state of the people involved.

Engineers can and do disagree on architectural choices and their consequences so there will always be some element of subjectivity in a debate over expediency versus robustness. But insisting that tech debt is always and everywhere the result of a choice leaves us with the odd situation where tech debt surrounds one system but not another even though the systems themselves are the same.

You might claim that Stu did make a choice – he chose not to search for a better solution! OK, fine. How do you know when your search is done? How do you know you aren’t just one more hour of thinking away from finding the Obviously Better Way to do it? Still, you might say, Stu could have tried.

Seeing technical debt as the cumulative effect of a series of bad choices focuses the problem on a search for blame. Which, to be fair, is a pretty common way of framing the issue.

Tech debt as a boring corporate morality play

Conversations about tech debt often have a strong whiff of moral indignation where the shortsightedness of others has produced a tragic outcome. Like The Ant and the Grasshopper rewritten as a tedious corporate psychodrama with maximal technical pedantry.

The moral dimension of tech debt explains why choice is so central to the definition – you can’t be responsible for a choice you didn’t make. If tech debt just happens then where are we going to find our scapegoat?

Metaphors have consequences

By what is probably a highly non-random coincidence, debt also has more than a whiff of unsavoriness, which could explain the enduring popularity of tech debt as a concept. It might just feel good to see it that way.

Our Stu scenario makes the metaphor even shakier though. How do we fill the boxes:

Does anyone owe rework to anyone yet? Will they ever? If some tech debt arrives in a code forest, does it make a sound?

In future posts I will defend tech debt as a useful metaphor, while arguing the definition of tech debt needs major rethinking. In the meantime, here’s a very good boy who doesn’t owe anybody anything.

.

I’ve never met or heard of anyone who said they had a different experience, like working at a company where all the code and systems were well-designed and up-to-date and thus “tech debt” never came up. Tech debt always seems to come up.

I also read a lot of technology books12 and the term “tech debt” is used freely and mostly without explanation. Everyone seems to assume everyone else knows what it means.

Reading Douglas Hofstadter3 has convinced me that metaphors are pretty much what thinking is, so it’s important to take metaphors seriously. I’m going to spend a few posts taking “technical debt” seriously to see what it reveals about how we think about technology and systems.

The parts of the analogy

I take the concept of debt to have three essential parts:

• Something that is owed

• Someone who owes it

• Someone to whom it is owed

If we are using the analogy well, then we should have clear mappings for each of those elements to our particular situation. Let’s start with the Wikipedia definition of tech debt, derived from Ward Cunningham’s original formulation:

the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one

In future posts I plan to look at the definition more critically, but it’s a good starting point to take a stab at identifying how things map.

Sally has a choice to make

Let’s say Software Engineer Sally needs to add a new feature this sprint. And she’s got two choices, the Quick And Dirty Way that will comfortably fit into the sprint, and a Somehow Better Way, a way that will probably perform faster, or scale higher, or be more maintainable. The second way is just clearly superior to the first way, but it’s going to take a lot longer, and we really need this feature now.

So, duh, she picks the first way! Don’t judge, it’s not like you haven’t been there. According to the definition, this seems to be the canonical tech debt creation mechanism: a choice to put speed first, knowing that eventually we’ll have to do some rework down the line.

How does that map onto the analogy? Let’s get it started:

Clearly what is owed in this situation is the future rework, that’s core to the definition of technical debt. It seems like Sally is the one who owes it because she’s the only person in the scenario so far and she did make the choice after all. Let’s put her there for now. Sorry, Sally.

But to whom does Sally owe the rework? If debt really is the right analogy here, there has to be someone in the last box. Could it be … Sally?

This sort of makes sense, she might very well be the person who ends up doing the rework. But, also, really? Can you owe yourself ten dollars? How would paying yourself back work? If this is really what we mean by “tech debt” then I don’t think it’s a great use of the metaphor. It’s like saying you owe yourself more trips to the gym. Maybe you think you should go to the gym more, but calling it a “debt” to yourself doesn’t seem to add any explanatory power.

Perhaps it makes a little more sense like this:

Maybe it’s a future version of Sally to whom Sally is now indebted. An older, wiser Sally who will look back on her youthful folly, shaking her head sadly as she painstakingly refactors what her former self wrote, thus repaying the debt.

Maybe.

But.

I Still Don’t Like That Answer

Because Young Sally isn’t the one paying back the debt! It’s Future Sally who ends up paying it back to herself. If technical debt is a proper metaphor then all the parts should map appropriately and so far they just don’t.

I want to propose another way of thinking about the metaphor, a way I will continue refining in future posts. Here’s a start:

This mapping makes more sense to me because the person who owes and the person owed to are different people. That’s a real debt!

Another reason I think this is a better way to think about it is that when a professional submits work into a value stream, there’s an implicit expectation of fitness for purpose, a basic expectation of quality. Providing high-quality value is the essence of being a professional. When we choose expediency over quality, we know we aren’t entirely delivering on our remit. And that’s how the debt comes into being.

Putting the customer of the work in the last slot makes the metaphor map, but I also think it raises questions about the original definition of tech debt. I’m going to take those up in some future posts.

I’ve been using GitHub CoPilot a bit and it’s really useful. I’m talking about the older version, not the one currently in beta with a chat interface. I’m sure the new one is going to be much better, but it’s already really good.

GitHub released some research showing that CoPilot improves programming productivity. Now it’s GitHub’s product and they charge money for it so what else are they going to say? But they also tell their own programmers to use it and code completion appears to be an obvious area where generative AI can be used to maximum effect:

• Code is much simpler and far less nuanced than human languages so the problem of usefully completing using an initial prompt is much easier than the general AI chatbot use case.

• Lots of programming involves writing ordinary “boilerplate” code that does something other programmers have done a zillion times before like:

  • Using a programming API to accomplish a standard task like creating a user record.

  • Issuing a database query.

  • Processing a form with standard inputs like name, email, phone number, etc.

  • And on and on and on…

• There’s an enormous amount of existing code to use as the training data and, critically, much of that code is known to work. So the training set is large and much of it is high quality.

The number of CoPilot users passed a million a while ago. Lots of other companies are getting into the generative-AI-for-coding game as well. It appears that AI-assisted coding is going to be a thing and it will produce a not-insignificant productivity increase.

When productivity goes up, you don’t need the same number of people to create the same amount of stuff. So one thing that could happen is that overall you build the same amount of stuff but with fewer people, i.e., some people will lose their jobs.

This has obviously happened in, say, agriculture, where thanks to mechanized farm equipment and fertilizers far fewer people need to be employed in agriculture today than were employed in the past despite the fact that we need to grow much more food due to population increases.

So it’s plausible to say that AI-assisted coding will mean fewer programming jobs. But if you are going to make that claim there is a serious problem you will have to face, namely this is hardly the first time that programming productivity has increased due to advances in technology. I will make what I think are generally non-controversial claims:

• Programming in higher-level languages is more productive than writing machine code or assembly and language design continues to advance even today, i.e., languages are getting even more powerful and thus more productive.

• Using sophisticated pre-AI Integrated Development Environments is more productive than using primitive text editors as you get:

  • Code highlighting and folding.

  • Limited (but still useful) code completion.

  • Interactive access to documentation.

  • Sophisticated code searching and navigation.

• The availability of open-source modules to accomplish standard tasks has been monotonically increasing over time and this increases productivity by reducing the amount of code you need to write yourself to solve a particular programming problem.

• Moore’s Law has increased productivity by vastly increasing the computing power available to run software.

• The rise of cloud computing increases productivity through a similar mechanism by putting larger amounts of compute and storage within the reach of more people.

Through all of this, the number of people employed in creating software in some form or another has been going up (though what we title those jobs has changed over time). In other words, every previous increase in software engineering productivity has led the world to collectively choose to make more software with more people.

The Bureau of Labor Statistics thinks the number of jobs in Software Developers, QA Analysts, and Testers is going up by 25% over the next ten years. Has the BLS just missed the boat on AI?

If you think AI is coming for programming jobs, then I believe the burden of proof is on you to explain why this time is different, i.e., why this time the world will choose to maintain the same amount of software with fewer people despite never having made that choice before. What that claim amounts to is that just as AI coding comes on the scene, the world has for some reason run out of new information problems to solve. This, I think, is an incredibly strong claim. I also don’t think it’s true.

This essay is about the word natural, wherein I argue:

• In older (but still very much extant) conceptions of the world, natural means something quite clear and relevant (assuming those worldviews are correct);

• But, in a materialist conception, natural doesn’t mean anything particularly useful;

• So, if you have a materialist viewpoint, you should probably stop using the word because it isn’t doing any honest linguistic work.

Isn’t it obvious what it means?

Natural medicine. Natural behavior. Natural foods. Natural products. Nature versus Nurture. Man versus Nature. What do we mean when we describe something as “natural” or pick out “nature” as opposed to some other state of being?

One would think we do know what we mean as “natural” is a relatively frequently used word in the English language. Still, I’m not sure what we intend it to mean makes any sense.

For example, what makes natural food natural? It seems to be the absence of “processing”, but only certain kinds of processing. Making honey, for example, requires quite a bit of busy bee business in which flower nectar is passed from bee to bee as it is broken down by specialized enzymes before being dehydrated (via bee wing beats) and stored in bee-manufactured honeycombs with bee-made wax seals. Honey doesn’t grow on trees you know! Also, bees are cool.

You can find honey at any organic and “natural” foods store. Why is this highly bee-processed product considered a natural food? Because it isn’t being processed by people. At least, not much. Presumably people are involved in getting the stuff into jars or plastic bears. Whether it’s food or medicine or any other sort of thing, the more people are involved in making it, and the more complicated their activity, the less natural the thing seems to be.

Let us consider why that should be so.

Where do people fit in the universe?

Mind-body dualism is the ancient view that mental activity is fundamentally distinct from the physical world. It is famously associated with René Descartes but has been espoused by many other thinkers and religions at least as far back as Plato.

Descartes held that only human beings had minds, while other animals were complex automata (robots), a position congruent with that of the Catholic Church where only people have spiritual souls independent from their material bodies.

In this view, people have two distinct natures, physical and spiritual, which correspond to two distinct realms. The triptych painting by Hieronymus Bosch titled “Last Judgment” captures this distinction well, including its moral aspects:

The middle panel depicts the grubby physical world on the bottom, clearly delineated from the radiant spiritual world on top. The material world has all sorts of base body business going on (and lots of people) while the spiritual world just has God, angels, and a few people. And trumpets, trumpets are also cool. The left panel (Eden before Adam and Eve were expelled) includes some animals and plants in the physical world, in addition to people. The right panel depicts the punishments that people receive if they give in to their physical natures.

People are the only element in common between the two realms and this is a key fact about people in mind-body dualism: they straddle the natural and the supernatural, and because of that people can do things that other living things can never do. They can write poetry, songs, and plays. They can talk and write and sing. And they can do good and commit evil. Because in mind-body dualism, people are partly magical creatures with unique powers.

The Creation of Adam by Michelangelo shows God bringing Adam into being via their outstretched fingers. It’s the poetry-writing end of Adam that is closest to God here, definitely not the pooping end or other naughty bits.

In mind-body dualism, when a person sits down to write a poem they are performing a minor miracle, that is to say, committing an act that cannot be explained by reference to the material part of the world. Because of the presence of human beings (and the active agency of other spiritual beings like God), some of what happens in the world is happening under a set of rules unconstrained by physical processes like physics, chemistry, or biology.

Given mind-body dualism, natural is a useful word

One role of language is communicating information to other people. In a universe where some things obey the rules of ordinary physical stuff while other things operate under a fundamentally different set of parameters, it’s going to be really important to know which is which. Is that approaching storm plain old weather or the embodiment of God’s wrath? The answer to that question determines what you do about it, i.e., you either take shelter or get down on your knees and pray.

If there really are two distinct but overlapping realms at work in the world, then we’re going to need ways of talking about them and natural (and its counterpart supernatural) will be an important and necessary part of everyday discourse, because knowing whether something is natural or not is going to be highly useful.

In mind-body dualism:

• There are two realms, the physical and the spiritual, with different rules and powers.

• Natural phenomena happen in the physical world and obey its rules.

• People (but only people) have intermingled physical and spiritual natures.

• People can do physical, natural things (like having a poop) that other animals do.

• Among living beings, only people can do spiritual, supernatural things, like writing poetry, giving a speech, or building a complex civilization. Their partly spiritual nature explains why only people do these things.

If you believe in mind-body dualism, then much that is notable about human activity compared to other creatures, like cities and complex tool-making and industrial manufacturing and TikTok, is not natural, because it is the result of people acting, for better or worse, with their spiritual powers.

Materialism collapses this scheme

In materialism and the related philosophy of physicalism, there is no spiritual world at all, no God, no angels, no magical forces acting upon the universe. Everything is made out of the same stuff and obeys the same rules – including people.

In a materialist worldview, everything that people do can in principle be explained by the structure of their bodies and their relation to their physical environment. An activity like writing a poem would likely have a very very complicated explanation, referencing fine-grained neuro-anatomical structure, physics, chemistry, electromagnetism, etc., but it would still be a physical explanation not essentially different from any other. Maybe we’d never be able to write down the explanation in terms of physical laws because it’s just too complicated. No matter – the point is that writing a poem is not magic, it’s a complex physical process of swirling matter and energy. It’s natural.

Materialism is the belief that there is just one world, the physical world.

If there’s only one world then all phenomena are natural phenomena. Pointing at a human-made thing and calling it unnatural makes no sense because there’s no principled way to separate human activity from anything else on the basis of naturality. If what you really mean by “natural” is “not made by people” then you should just say “not made by people” and avoid confusion.

Wrapping Up

Ok, so maybe people won’t stop using a 5000 year-old word because a random person wrote a substack telling them not to. Maybe “natural” is a concept where you know it when you see it. This would all be fine and good except that nature is often invoked to justify a certain state of affairs, i.e., “natural” is often used with normative rather than descriptive valence. Natural foods, for example, are considered healthy by default but foods that people make might or might not be.

There is a curious inversion going on when natural things are considered good by default and human-made things are guilty before being proven innocent. This is probably not what Descartes had in mind unless you flip “natural” to mean “what God wants to happen” whereas people can fuck things up because of magical free will and all. But either way, a materialist can’t use “natural” coherently.

For a materialist to say something is good because it is natural is sneaking in an argument from authority that is doubly-suspect because materialism means there is no authority to appeal to. Materialism means it’s nature all the way down.

As a materialist myself, I’m going to do my best to stop using “natural”. You do you!

Share

Troy Vettese and Drew Pendergrass wrote a book called “Half-Earth Socialism”. The title is a reference to “Half-Earth” by E.O. Wilson, which I haven’t read but which I gather argues for preserving biodiversity and the environment by dedicating half the Earth to non-human life. E.O. Wilson is a distinguished biologist and you should read his books. Dude knows his ants.

The authors agree that half the Earth should not have any people, and furthermore add that the other half obviously needs to be organized as a unitary socialist command economy, something the “centre-Left Democrat” Wilson just fails to understand.

Obvious or not, one tricky problem with such a plan is that previous large-scale attempts to boot up really-existing socialism have not been entirely awesome. Lenin’s and Stalin’s USSR, Mao’s China, and Pol Pot’s Cambodia ended up murdering and starving an awful lot of people, a fact the authors obliquely allude to.

So how does one run a socialist, environmentally-friendly, planned-economy utopia without all the murdering and starving? The solution the authors propose has three components:

• Linear programming to maximize or minimize a particular quantity (say carbon emissions) under a set of constraints involving other quantities of resource inputs and consumption over the world economy. In other words, central planning with algorithms.

• Supercomputer-assisted world-wide simulations of material resource flows and their environmental impacts to set the production and consumption quotas for the socialist collectives located in Half-Earth so that in aggregate they meet the targets output by the linear programs under dynamically changing conditions.

• Democracy

Interesting!

The point of all this is to manage an economy that feeds 10 billion people in an environmentally sustainable way while avoiding anything that looks remotely like a market with a “universal equivalent”, i.e., a currency. Rather, the trade-offs between, say, building a solar farm versus a potato farm need to be done using “in natura” calculation per the philosophical writings of Otto Neurath.

The appeal of using linear programming appears to be threefold:

• Because the equations are written using “in natura” units like kilograms of steel, megatons of carbon, etc., you don’t need a currency to intermediate the trade-offs via price levels and supply and demand.

• Linear programming was invented by a Soviet mathematician, Leonid Kantorovich.

• Linear programming is a “quintessentially Socialist kind of mathematics”, no kidding.

It honestly never occurred to me that the real number line might care about your politics, but here we are. Given how frequently linear programming is used to make business decisions in capitalist enterprises, this is a really weird belief.

The authors concede that linear programming by itself will be too inflexible to plan a global economy with lots of feedback loops. See Red Plenty for a brilliant and sad meditation on the failure of linear programmed central planning in the Soviet system with some cameos by Kantorovich himself.

This is where the supercomputer-driven simulations come in. The simulations will manage short-term adjustments to the top-down plan in terms of what needs to be produced and where. The simulations will also take into account climate effects much like climate simulations are used today to forecast global warming trends. At least that’s how I think it is supposed to work because this part of Half-Earth Socialism is only vaguely sketched out compared to much longer sections about Kantorovich and his invention of linear programming.

What is completely left out is where the supercomputers come from. Supercomputers are powered by advanced semiconductors, the development of which is the apotheosis of market capitalism. See the excellent Chip War by Chris Miller on the history of the semiconductor industry and the attendant increase in computing power and Moore's Law. In Half-Earth Socialism, where do the chips get made, who makes them, and why? Troy and Drew do not say.

Taken together, linear programming and supercomputers are supposed to organize and command the global economy to feed and house around 10 billion people without anybody starving and without cooking the planet, albeit with significantly less material resources available per-capita compared to modern industrial economies.

That takes care of the starving; what about the murdering? Apparently, this is where the democracy part of the plan comes in, but I can only say apparently because even less is said about how that will actually work. The authors take pains to emphasize the practicality of their scheme, but setting up and running a democracy for a single nation has proven to be a consequential task and many such attempts have failed or eventually resulted in back-sliding to authoritarianism or oligarchy.

Setting up a global democracy starting from the current state of the world seems herculean. The authors mention a couple of times that the democracy/linear-programming/simulation scheme happens “after the revolution” but provide no details at all on what sort of revolution it was – did it have a lot of murdering during the revolution but not after? Again, the authors do not say. How we actually get from here to there without the reins of power being seized by bloodthirsty autocratic sociopaths seems like a pretty important detail and its lack is the biggest lacuna in the book.

You might wonder what a resident in the world-democracy will actually be voting for since much of her life will be organized by equations and simulations rather than her own sense of what she might want to do. Will it be what sort of government she wants? Don’t be silly, she wants Socialism, of course. No, the real question for voters is: what is the set of linear programs that should be used for global economic planning?

A democracy where people elect the equations that will rule their lives is certainly a striking idea. We shall all be Cyberneticians in Half-Earth Socialist Utopia.

In the last part of the book, we learn what everyday life in Half-Earth Socialist Utopia will be like through a fictional account using the same trope as News from Nowhere in which the main character, William Guest, falls asleep in the present time and wakes up to experience a day of life in the future.

In the Half-Earth Socialism version, William wakes up in a small-town collective located in the Northeastern part of North America. As William encounters some of the residents, they cheerfully, almost manically, spout on about how awesome everything is compared to the before-times and how much better their lives are while explaining to William the basics of the local economy and social life.

This is off-putting for a couple reasons. First, even if you like your life you generally don’t accost random people to tell them about it. But this behavior makes a lot more sense if you assume that everyone suspects William of being a member of the secret police and are trying to avoid being sent away for reeducation.

The second weird thing is that life in Half-Earth Socialist Utopia doesn’t actually seem all that great. Do you like to go on road trips? Or travel to distant cities or continents? Or go to movies or concerts or restaurants? Or possess a modern cell phone? I sure hope not, because it doesn’t appear you’ll be doing any of that. As best as I can gather from the short story, much of life in a present-day modern city will no longer be available to the citizens of Half-Earth Socialist Utopia.

Mostly, it seems, they are going to be farming and riding around on bicycles. Because there won’t be any manufactured fertilizers, there will need to be a lot of farming, and since there won’t be much in the way of modern farm equipment (or cars for that matter), a lot of that farming will be by hand.

I realize that some people really do like farming so maybe this life would count as utopia for them. That said, at least in the United States, a lot of the people who do appear to like farming don’t appear to be especially enthusiastic about Socialism or bicycles. Evidently Drew and Troy really like all three. I am skeptical, though, that there are enough people so excited about being farmers who rarely leave the town where they live (and need special permission from the authorities to do so) that they are willing to staff the barricades of a successful revolution to force everyone else live that way too.

I did enjoy Half-Earth Socialism. I like most any book that is reasonably well-written and has information and perspectives new to me. I hadn’t heard of Otto Neurath or Leonid Kantorovich and I didn’t know about the abortive Soviet attempt to use linear programming for central planning. This book inspired me to read the (much better) Red Plenty by Francis Spufford.

I don’t think I want to live in a Half-Earth Socialist Utopia, though, and I’m skeptical that the plan for it as sketched out in the book is as practical as the authors claim.

That much of the present-day modern world will get “un-built” in Half-Earth Socialism puts the book firmly in the degrowth movement. My reaction to degrowth is: no thanks. I suspect any such un-building would be accompanied by a horrendous amount of violence and that is why the authors tiptoe around the actual revolution needed to bring their utopia into being.

The premise of substituting equations and simulations for a market with a currency is that a market is fundamentally solving a computational problem and that with sufficiently powerful computers we could solve the problem directly, but with a more equitable outcome than currently produced by market capitalism. But what if markets are really solving a cognitive or knowledge problem that central planning, computational or otherwise, cannot solve because the central planner has no access to the tacit knowledge distributed amongst individual people and situations?

The description of life in Half-Earth Socialist Utopia dovetails curiously with that sketched out for the pioneer communities in the latest installment of Brink Lindsey’s The Permanent Problem, a series of meditations on what Lindsey thinks has gone wrong in modern society that is just now getting around to proposing what we should do to fix things. Given Lindsey’s Libertarian leanings, it’s quite curious that he’s arrived at a somewhat similar solution. It’s only kind of similar because in Lindsey’s scheme people freely choose to establish and live in these self-sufficient communities rather than being forced to, all while a market economy continues to run alongside them and there is no central planning.

Lindsey is also pro-technology in a way that Vettese and Pendergrass clearly aren’t. Half-Earth Socialism only grudgingly accepts supercomputers and solar power as necessary parts of the plan, while insisting that most everything else created in the last several decades needs to go. This conveniently brings the world back to modes of production that Marx and Engels would have recognized.

It’s interesting to think about Libertarians and Socialists agreeing that capitalism has overreached and produced a society operating at scales fundamentally at odds with human thriving and that what we need are smaller, human-sized communities and economies that create and sustain the relationships sundered by globalist market forces.

Some Further Reading

I found these articles useful when thinking and writing about this book.

https://www.liberalcurrents.com/degrowth-neither-left-nor-right-but-backward/

Noahpinion

Degrowth: We can't let it happen here!

A year and a half ago, I wrote a post entitled “People are realizing that degrowth is bad”. Around that time, the degrowth movement had started to receive a bit of attention in the U.S., as part of the general push for major action on climate change. But writers like…

Read more

3 years ago · 177 likes · 79 comments · Noah Smith

The Permanent Problem

Rebalancing Capitalism

What would success in grappling with humanity’s permanent problem look like? How do we get to a society where most people are able to “live wisely and agreeably and well”? In the past couple of essays, I’ve focused on the technological changes needed to resolve the deep conflicts opened up by …

Read more

3 years ago · 13 likes · 22 comments · Brink Lindsey

Witness the many Return To Office initiatives requiring workers to be back in company buildings at least a few days a week. Stated rationales for RTO include:

• Collaboration, including scheduling and decision-making and communication, is easier and more effective when employees are in-person.

• New employees receive better training and mentorship from their peers in-person.

• Company culture and morale improve when people are physically together.

• Spontaneous “water cooler” conversations involving people who wouldn’t normally encounter each other in their usual round of remote meetings can spark new ideas and deepen organizational relationships and weak ties.

You can imagine there are other reasons companies might want employees back in the office — reasons they might not want to say out loud. For example, it could be easier to monitor employees’ productivity and work habits when the bosses and workers are in the same building.

Let’s go ahead and assume that at least some of the leaders calling for RTO have positive intent and furthermore that some of the points above could be valid. Remote communication is a very recent phenomenon from the perspective of human evolution so the claim that in-person collaboration is more effective could have merit.

We communicate with each other with many layers of nuance including vocal tone, facial expression, hand gestures, body posture, physical distance, etc. When we are physically together we experience each other through multiple senses with extremely short delays. But the current suite of collaboration tools flattens us into tiny 2-D videos that show just the face and partial upper body with relatively low-fidelity audio and frequent lags.

So the claim that in-person collaboration is better than current options isn’t outrageous. Recent research supporting the value of in-person interaction includes the effects of the pandemic on learning loss in US schools, the negative effects of online lecture availability, and the benefit of local collaboration in academic learning.

Conversely, people really, really like the option to work remotely and value the autonomy and commute time savings that remote work offers. The National Bureau of Economic Research found that remote work saved over an hour of commute time each day. That is a crazy amount of wasted time (and energy, a lot of it generated by fossil fuels) that isn’t remunerated. Furthermore, the NBER found that some of that time saved is spent working!

All of which means the case for RTO is mixed. Working together in-person seems to have clear benefits but working from home does too. So “hybrid work”, where employees spend some amount of time physically co-located and spend the rest working remotely, is an obvious compromise.

Hybrid work has to be more than designated office days

The simplest hybrid work policy is “everybody comes in on these particular days of the week”. Simplicity is the only nice thing about this policy, otherwise it’s not fabulous:

• It’s ham-fisted: requiring people to come in reduces the autonomy over their own time that people clearly value.

• It doesn’t cover all employees: companies have taken advantage of remote work to hire people geographically distant from long-term company real estate and to reduce their office footprint (and thus expense) below levels that would comfortably accommodate everyone simultaneously.

• It’s inefficient: while working in-person with certain people is useful, it’s not like you need to see every person in the company when you go into work. Requiring everyone to be in the same building at the same time when only a fraction will actually collaborate together on any given day adds up to a lot of wasted commutes.

• It doesn’t solve the problem: A lot of the people you need to collaborate with will be at different sites, or different organizations, producing the “I went to the office and spent all day in online meetings” effect – the worst of both worlds.

Remote tools can get better

First, let’s acknowledge that current online meeting systems are a huge improvement over conference calls, which are themselves miraculous compared to any previous remote communications technology in human history. It’s easy to forget we live in a time of unprecedented technological capacity, albeit very unevenly distributed.

We can imagine better tools without disparaging the ones we currently have. So far, the “metaverse” has been risible hype, but the impulse to provide a more immersive collaborative experience is completely understandable. By all means, keep making fun of Mark Zuckerberg who deserves all the jeers he gets and more, but let’s cheer the people quietly working to make remote collaboration better. I would gladly trade a small screen of tiny people in boxes for an immersive 3-D view of whole people with accurate hand and facial gestures, high-quality lag-free audio, etc., but without a ridiculous and bulky headset. I hope some smart folks figure this out!

Coordination tools can get better

Ham-fisted as it is, forcing people into the same building every day mostly solves the “coordination problem” between the people at that site. That is to say, if you and I work in the same location and I need to talk to you, I can just walk over to your office or cubicle and there you are – because you have to be there just like I do. Coordination problem solved!

We can do better. The coordination problem is an information problem:

• Inputs:

  • Who needs to talk to whom about what

  • Where are people located

  • When are people available

  • When they can be in the office

• Outputs:

  • When we shall meet

  • Where shall we meet

  • Will it be virtual or in-person?

Since we are supposedly living in the Information Age, it’s disappointing how often scheduling a conversation boils down to something like this:

1. I send you an email with some free times I picked from my calendar at random.

2. Some time later you notice the email and open up your calendar and cross-check your free times with the ones I sent you. None of them work. You pick some random free times from your calendar and reply to my email with them.

3. Some time later I notice the email and pick one of the times you sent and reply to you.

4. In the time between you sending the email and my reply, the time I picked was booked. We go back to step 1, missing a small piece of our souls.

There are applications like Calendly that supposedly solve this problem, but in practice they just move the effort all on one person, the person without the Calendly account who gets to cross-check their calendar with the other person’s free time. The solution is not for everyone to have Calendly accounts, though Calendly probably disagrees.

Here’s what I really want:

1. I know I need to talk to you about something, so I tell my calendar I want to talk to you about that thing.

2. My calendar talks to your calendar. Our calendars know:

   1. When we are free.

   2. Where we are going to be when.

   3. Days we could go into the office if someone was there to actually talk to.

   4. Other options for where we could meet if we happen to be near each other.

3. The only thing you need to do is indicate if you are willing to talk to me. The calendars take care of the rest:

   1. Picking a time when we are both free and scheduling the conversation.

   2. Creating the online meeting or booking the meeting room or co-working space. Or just picking the coffee shop where we could get together!

   3. Letting us know the days we need to be in the office and by when.

   4. Bonus points for minimizing commute times and putting multiple in-person meetings at the same location on the same day.

Nobody has to play calendrical Tetris and we only commute if there’s an actual in-person conversation to be had at the end of it. And this should work even if we are using different calendar applications. Standards and protocols are useful for a reason.

I can imagine a similar function to help people get together just to be in-person:

1. Each person indicates days they would go into the office if they knew it wasn’t going to be a ghost town.

2. The system now knows which days could achieve “critical mass” if only everyone willing to come in knew it – and tells them!

Current calendar systems work mostly like semi-shared spreadsheets with cells we all have to fill in by hand. They should be focused on helping us have the right conversations in the right ways with the least amount of commuting and fuss.

Policies can get better

Better tools can't compensate for bad policies. Between “everyone works at home” and “everyone comes into work five days a week” there are lots of possibilities and policies should be designed after figuring out what concrete outcome they are supposed to achieve. “Everyone geographically near a company office comes in on these days” is not the same outcome as “There are lots of opportunities for in-person collaboration and spontaneous conversations while maximizing autonomy and flexibility”. If the latter is what you say you want, then think much more expansively about how to produce that outcome and then form your policy.

Here are some suggestions:

• Choose collaboration tools that help people discover opportunities to get together in person and help people use them to full effect.

• Incorporate co-working spaces into real-estate planning. Office space is going to be cheap for the foreseeable future and co-working offices can be a low-cost option for occasional in-person collaboration that can be deployed wherever there are geographical clusters of team members.

• Demand more from your productivity suite provider – calendars could be much smarter!

• Demand more from your online meeting provider – tiny people in boxes can’t be the last word!

If you are working for a productivity tool company, take the need for in-person collaboration seriously. The arguments over RTO can disguise the fact that lots of people genuinely like working in-person with their peers and there is a growing body of evidence that it can produce better outcomes. Productivity tools need to get a lot smarter about geography and available working spaces (including bookable co-working options).

Hybrid work should just be work

Being in-person is not optional for lots of jobs. But we now know it is optional, at least some of the time, for lots of other jobs. Large numbers of people worked from home for the last three years and work got done. It no longer makes sense to presume that unqualified “work” means going into an office and anything else needs to be qualified as “remote” or “hybrid”. Commuting is a big expense, including wasted time and environmental costs, and that expense needs to be justified either by physical necessity or some other equally compelling reason. Absent a good reason, people shouldn’t have to do it.

It could absolutely turn out that working in-person some of the time has significant tangible benefits. Great! Let’s help people to do that with tools and policies that still provide autonomy and flexibility.

Furthermore, people who really have to be physically at work should be compensated for the time and expense of commuting. This is where better tax policies would help. This website explains that you can’t deduct your commuting expenses, but gets the justification for that state of affairs exactly wrong:

You cannot deduct commuting expenses no matter how far your home is from your place of work. Consider it like this: Everyone needs to get to work, employees and business owners alike.

Ok, I considered it like that and it’s totally wrong, it’s obviously empirically false and we all know it. Let’s consider harder and then come up with tax policies that encourage less pointless commuting and compensate people who need to commute because of the nature of their jobs.

Hybrid work is just work without pointless commutes.