Rebuilding in software

A lesson from "The Unsettling of America"

So, I am more or less finished with reading The Unsettling of America by Wendell Berry. Unfortunately, because it was a library book, I was unable to write in it. And without the ability to annotate, I find I can’t engage with it all that well*.

But! One idea though that has stuck with me, a “cherry-pick” of the book so to speak, is the cyclical nature of soil (from Chapter 6, “The Use of Energy”):

The soil is the great connector of lives, the source and destination of all. It is the healer and restorer and resurrector, by which disease passes into health, age into youth, death into life. Without proper care for it we can have no community, because without proper care for it we can have no life. It is alive itself. It is a grave, too, of course.

But no matter how finely the dead are broken down, or how many times they are eaten, they yet give into other life. If a healthy soil is full of death it is also full of life: worms, fungi, microorganisms of all kinds, for which, as for us humans, the dead bodies of the once living are a feast. Eventually this dead matter becomes soluble, available as food for plants, and life begins to rise up again, out of the soil into the light. Given only the health of the soil, nothing that dies is dead for very long.

In my world of software libraries, I encounter “death” quite a bit— claims that a product is “dead”, project post-mortems, abandoned half-alive ideas. I see “dead” code, orphaned functions, obsolete tickets, graveyard directories. Some of this is just normal tech debt that will be tended to by a civic-minded engineer. But there are larger failures, i.e. valiant attempts to rescue a codebase, that I’ve struggled to accept— why did they fail? And how do we learn from them?

When the codebase is un-maintained and bloated, it is extraordinarily difficult to develop. Not a lot of code is submitted, and the code that does is often very hack-y. In this type of development environment, you will see a lot of failed projects. These projects fail because of the poor relationships between software components (unclear layering and API boundaries) and poor relationships between software and people (slow engineering velocity). I suspect that these problems are downstream of poor relationships between people.

Because the software development environment itself is so broken, it cannot sustain “life” or any meaningful progress. When the codebase is in poor health, everything suffers and when the codebase is in good health, everything flourishes. So then my next question is—how can we make this environment whole again?

I’m still trying to make sense of my answer, but one insight this passage revealed to me was that I can view the failure of these projects as not a waste but rather a natural and necessary step in the process of rebuilding. In the same way that we revitalize soil by burying “life” or organic matter in it, one way to revitalize software is to work on projects that ultimately get scrapped.

The most important part though, which I’ll save for another time, is what people do after their project fails. Unlike (healthy) soil, dead things in software do not re-incarnate themselves.

*This is my excuse at least. Years of low-latency consumption may be a better reason.