The Software Grief Cycle

People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.

- Source lost on the Internets

After reflecting upon my last Weekend Reader, I came up with some more thoughts about the fact that software is eating the world and the  long-run problems that result from the fact that we create new systems at an ever increasing rate.

Tudor plays with the idea of “Software Environmentalism". This implies that there was a clean environment that gets polluted by software systems. The assumption is, that, as in nature, the environment can only deal with a certain amount of pollution, therefore we must start taking care and according to Tudor's idea:

No system should get away without dedicated tools that help us take it apart and recycle it effectively.

Let’s see what Steve Jobs once claimed about software: Eventually it collapses under it’s own weight!


Let’s repeat:

"It doesn't matter what you do, eventually it will collapse”.

It's like with humans and death ... it's inevitable. We can prolong our lives by living healthy and modern medicine sometimes allows to keep us alive even when it does not make much sense any more ... but we all are getting old and finally we will die.

So there you have another analogy, actually a full bag of analogies.

Any software will age and finally it will die. 

Some software will age more gracefully than other software, but they all will die. We have to accept that. This is not an easy insight, there are the five stages of grief (denial, anger, bargaining, depression and finally acceptance). Letting the software die might become painful for everybody involved… especially if you try to deny the fact. Often developers are way ahead of management on the stages of grief:



I would argue that we are still dealing with a very high mortality rate in the software industry today. But we are not dealing with the tragedy of stillborn children or sudden child death. No, in the software industry we mostly deal with monstrous frankensteinian abominations that will not be able to breathe on their own. Still we keep trying to somehow create the perfect monsters ...

Often we are helpless in dealing with dying software. There is also a lot of software that should have died a long time ago, but it was not allowed to. Nowadays there are armies of maintenance developers defibrillating, heart-massaging and mouth-to-mouth breathing thousands of zombie systems all over the world.


How can we deal with dead and dying software?

Maybe we just have to be more cruel (and more honest) and accept their death. Maybe this enables the rest of the software population to live healthier, maybe even to thrive and prosper… the other important thing here is to get rid of the dead. Make a clean break, don’t keep the dead (or  almost dead) software lying around. Dead or dying software has the tendency to keep you incredibly busy. If you are not cruel, you won’t get rid of it:



Different cultures dealt differently with ageing and dying individuals. A well known example is the senilicide in ancient Eskimo culture: Old people that could no longer contribute to the well-beeing of the group were cast out to die in the snow. This certainly was a very cruel way, but it ensured the survival of the group in times of scarcity.

It is a well known fact, that enterprises have big problems finding developers to maintain their legacy systems. Developers often are not motivated to deal with legacy software. The lack of good developers that deal with legacy software, makes maintaining dying systems even more difficult and can accelerate the rotting of that software.

So maybe this is the cruel way in the software development ecosystem: In times of scarcity, developers choose which systems should die by refusing to work on them ...