Biologists will tell you that life has 7 characteristics: organization, metabolism, irritability, reproduction, homeostasis, adaptation, and growth.
I think this list is missing something. It’s foundational, indisputable, and familiar even to kindergartners. But perhaps only kindergartners would call it out; several generations of biologists seem not to notice it enough to add it to their short list. Pick up a biology textbook, and you are unlikely to find a single chapter devoted to it.
Are you ready?
The 8th characteristic of life: mortality.
All living things die.
Think about the consequences for a few moments. Would any of the ecosystems that you see on nature documentaries be possible without death? Would human civilization, as we know it? Read Orson Scott Card’s short story, “Mortal Gods,” and ponder.
Why am I writing about this as a software guy?
As I’ve written before, I believe life has profound lessons for software engineers. And death is a biggie. (I’ll probably devote at least one chapter to this in my forthcoming book.)
To be fair to biologists, their discipline takes death into account constantly. Its existence colors narrations about food webs, survival of the fittest, decomposers, and thousands of related topics. Biologists are well aware of its ramifications.
But the fact that death didn’t make their distilled list of 7 fundamentals is telling. If brilliant minds forget to state the obvious in that context, would it be any surprise to see the mistake repeated in the world of bits and protocols?
Pervasive software death
Hardware dies. We usually get that one. We know all about MTBF (mean time between failures) for hard drives, RAM, and the like. Interestingly, this phenomenon sometimes gets labeled “half-life”, which has roots in a biological metaphor despite its direct borrowing from nuclear physics.
The other kind of death that software engineers routinely acknowledge is the Blue Screen of Death and its cousins (the abend, the seg fault, the panic). Strictly speaking, this is the death of a process or accumulated state, not the death of the product engineers worked so hard to build, and although we try to prevent this type of death, we don’t spend a lot of time pondering it.
What about sublter forms of death, though?
Software products die. Consider VisiCalc.
Software versions die. Seen any Windows 3.1 lately?
Software companies die. When was the last time you bought anything from Caldera?
Software protocols die. Software installations die. Software expertise dies. Software standards die. Software fads die. Software markets die. Vendor and OEM relationships die. Competitive advantages die. And on and on.
Software death is a good thing. As in biology, it makes room for new and more evolved growth. It gives me job security. :-)
But I think software companies–all organizations, not just the dev organ–would be happier if they acknowledged this death and planned for it explicitly. For example:
- We should announce a lifespan to a product that starts with its birth (release). Do we expect it to live 3 years? 5? How long is support on the hook to keep it on life support? (Some orgs do this, but it’s a less common practice than it should be.)
- As humans cope with death through wills, trusts, and inheritance laws, so software orgs need to plan, carefully and well in advance, for the upgrade experience implicit in the next generation release. Otherwise we’ll get mired in messy and expensive probate procedures. Is there a “death tax” that makes it hard to transmit hard-won earnings forward? If so, can we minimize it?
- Developers should recognize that the technologies they depend on today will eventually be buried. Plan to switch horses before the one you’re riding kicks the bucket. (Hence the importance of continuous learning.)
- In biology, some forms of death have warning signs. Does our software notice these, and take measures to protect itself? Do we tell the customer that software is in danger?
- Do we provide a way for the customer to take our product off life support if that’s the right decision?
Please reply to this post with your own thoughts about where death needs better explicit handling in the world of software.