Last week I killed my own code. I’ve pulled the plug. I’ve sunsetted it. I was surprised: it really didn’t feel weird at all. Maybe I should have felt something. In the end this was my first project at my current company and the first time I was publishing a GitHub Action. It felt natural, and I felt I was doing the right thing. In the following days I kept questioning myself: why did this happen?
I’ve understood that the project might not be successful
The project aimed to solve a problem that could have had multiple other solutions, of which many could have been fixing the culture in the organization or throughout a #nocode or #lowcode implementation. Each one of them had some concerns behind. The chosen way to solve it also had a couple that could have made the project overall unsuccessful. This understanding helped me while building and maintaining this piece of software in two ways: don’t get attached to the solution and understand the energy I should be investing here.
There was an even better way to build it
As I was advancing towards the completion of the project and deep-diving on the implementation details, I’ve realized it’s different problems, mainly from an architecture standpoint. There were some improvements to be made, and, overall, more efficient ways to have built it. The balance of delivering what we have vs. improving it leaned towards the first one, to give space for delivering other initiatives. A bit after rolling the solution out, while working on releasing our first bug fix, some of these problems were confirmed. I realized that one day, the solution will need to be replaced.
Nothing lasts forever
On a more philosophical note, most of the things we build as humans are ephemeral. We create things to help us with a particular need, until that need no longer exists, the initial need is extended or we discover a better way to satisfy it. And this happens even more in technology and software. We deprecate or flag as obsolete our creations at a very high pace. Each day passes, it’s one day closer to the moment that the code we’ve written it’s no longer needed.
Look at it from a different angle
If you’re working in technology, no matter the position you’re in, it’s important to create healthy habits that can help you and your organization evolve. Being attached to a solution, a particular piece of software or tool, can keep you from continuously improving our organization and yourself as a professional. However, most of us still do it, and it’s normal. We’re human beings and most of us do get attached to things. Nevertheless, creating a mindset around the following facts:
- Being humble. Any solution has some weak spots that can, one day, be the reason if it is not needed anymore.
- Understanding that what you’re building (in its actual form) will eventually become obsolete.
- Challenging the solution yourself throughout the different phases of a project (development, maintenance). Understand why it might fail its purpose.
- Deprecating obsolete things you’ve created if you have the occasion.
- Learn from this process and take conclusions that will help you extend the life cycle of our next projects.
Will help you stay positive about sunsetting your own creations and allow you to grow.