You might be aware of the Kübler-Ross model (known as five stages of grief). It is a model designed to postulate the progression of emotional states experienced by terminally ill patients after diagnosis.
The five stages are chronologically: Denial, Anger, Bargaining, Depression and Acceptance (source: Wikipedia).
Today I don’t want to write about the original Kübler-Ross model, but an application of it on dying software projects.
How are we dealing with dying software projects as developers?
As software developers, we are often identifying ourselves with our work. As a result, we often suffer if things are not going right at work.
For myself, I am just about to depart from actively working on a project. It was the first real big project after finishing my degree and I was really involved and invested. Even today I am still working daily on it, but soon I will be out.
Due to it being “my first”, calling it quits wasn’t easy. Not only for me, but also for colleagues who were in the same situation. So what was happening with us?
Looking at it now, shortly before it is over, I see a lot of parallels to the Kübler Ross Model.
Let’s go over all the stages and see how we lived through them and how it affected us.
Denial
Due to being in direct customer contact back then, I was pretty early aware of the rumors about a follow-up project. In fact, there were only rumors and no clear signs. We all were pretty much denying the possibility of this happening.
“It will take too long to restart it”, “They will not able to re-build it quickly”, “It is just impossible to go for it”.
It will not happen!
A while later our management informed us that there is a parallel project. It will be basically re-writing our core features and will be used for trying out new things. It is not directly planned that it will be replacing our project.
Anger
We came to the conclusion that denying was not an option anymore. In the meantime another project team was formed and that they worked on building a POC with our core functionality. As a result, some of us became really angry.
Why does it need to happen? Why our great project?
Bargaining
“What if we improve our App Store Ratings?”, “What if the other project is not delivered on time?”. “What if we improve the quality and get rid of all the issues we have?”.
In this phase we delivered a lot of high-quality improvements which helped to make our project more stable. I think this made it a bit harder for the new project team to easily sell off their first version, since a lot of planned improvements were not improvements anymore.
Customers were quite happy with the changes – but this didn’t change anything about the upcoming sundown.
Depression
We saw Screenshots, we saw prototypes. We were not happy about it.
You could feel it during stand-ups, during meetings and you could feel it when we were doing our plannings. More often you could hear replies from individuals which were similar to the following sentences.
“What’s the point, if it will be gone in half a year anyway?” “Why go for that refactoring? Why improve the quality?”, “Why should I even care?”.
Acceptance
Sooner or later the overall mood kind of improved. More often you could hear people even cracking a joke about it. More and more developers know already to which project they will be assigned next or they already had their next job lined up.
We all let go.
For me it was really surprising to see the parallels to the original model. I think with the knowledge about what is happening you can better understand your and your teammates’ emotions. Farewell!
Having any comment or feeling about the post? Feel free to reach out via twitter.
About the Author:
