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.
We see without seeing… Photo credit: John O’Neil (Wikimedia Commons)
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.
Community blindness
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.
So what?
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?
Action Item
Please reply to this post with your own thoughts about where death needs better explicit handling in the world of software.
Codecraft 
As recently as two years ago, I was still providing support for a product originally released in 1996, last updated in 2002, and still (at that time) being sold. The only reason it happened was because we charged an annual fee for support. That said, nobody had bothered to figure out if the cost of supporting this ancient product was exceeding the revenues generated by it, especially when considering that support resources would best be spent elsewhere.
I’m sure customers were thrilled that they could keep on using the same piece of software for 15 years, but it would have been a better service to them to help them transition to a newer platform, and it almost certainly would have made a lot more business sense.
Jesse: Amazing how old software gets! In the late ’90s I was working on code that had comments from the early ’70s. Crazy.
It is my understanding that, in biology, there’s a concept called “biological immortality”, in which, short of disease or injury, the organism simply won’t die. Perhaps there’s room for such a thing in the software world. Software, in a way, is the embodiment of ideas, and ideas are eternal–they exist before anyone thinks them, and continue to exist after they are forgotten. (Even so, I consider them to be alive.)
Indeed, sometime code can achieve a certain toe of immortality–Eric S. Raymond, several weeks ago, blogged about how robust a certain image processing program was, decades after he first wrote it! Sometimes our understanding of a given problem domain becomes so mature, there isn’t much of a point in messing with the code–and there are more problems like this then we realise.
Having said that, I can’t help but think about how, while certain tortoises may be immortal, humans literally have mortality encoded into their DNA–so mortality exists for a reason, and probably several. Thus, planning for mortality, and occasionally checking up on the “immortal” stuff, to make sure it still deserves life, makes a lot of sense to me.
And now that I think about it, it drives me nuts that I have a tablet that is probably a little more powerful than a laptop that recently died on me, but is so Android-centric. It ought to be able to run LaTeX just fine, but it cannot, because Android hides the processor from me! The Linux ecosystem represents thousands, and perhaps hundreds of thousands, of man-hours of coding, in all sorts of languages beyond Java, all of which is out of reach unless you do drastic things to your device (namely, root it and install some form of Linux).
Alphy: thank you for pointing me to the “biological immortality” concept. I went and read the wikipedia article. Fascinating!
All rules have exceptions–even this one, I guess. :-)
great observation and life process event handler.
I have been offered several jobs in my 33 years to work on the back side of a ‘system’ who was on life support, but no one wanted to ‘improve’ the same. Just keep it ticking until the income dropped below some ‘exit criteria’ level.
I said, no thanks. I prefer to be on the front side of the curve, thank you, and even at the point of conception. THAT is fun
It *is* fun to work on the front side of the curve. No doubt about it. We became engineers because we liked building something new and wonderful. I wish business people would let go of the misconception that once a feature has been built, it is “done”–and that it will continue to make them money in perpetuity. The truth is, features have carrying costs, and the health of a codebase requires steady maintenance and periodic upgrades.
Intereesting read