Releasing Is Part Of The Process #

I have seen many roadmaps end with big words “RELEASE”. Many teams, colleagues and even myself, give it all to make it to that last final step as if all the problems would go away once the software is released. Whatever happens afterwards, happens and is no longer our problem is a naive and unrealistic approach.

But it turns out it is our problem and it is only made worse by this myopic focus on the goal to release, wrongly believed to be the last step. We cut some corners, stick things together with duct tape and hide them behind something pretty, write a bug as an “exception that should not happen normally” and move on without further investigation and many other things that helps us move faster towards our end goal, the “RELEASE”.

The result of hurrying only makes matters worse when, at the end, we realize we are not, in fact, at the end, but we are at a step in the whole process and now we have to live with the mess we have made and, more often than not, redo the work in order to untangle everything. “Software of quality” should be a check for the release to be even considered and without it, there should be no release.

To make things worse, as if refactoring a bad codebase is wouldn’t be enough, the feedback phase, that comes after releasing, begins and the first impression start flooding our inbox with questions from confused users asking if they are doing something wrong or if the software is not working as expected. The stakes get higher once our software is out and into the users hands than they were before the release which puts even more pressure on an already fragile and unstable software product. This situation has very high chances of having a snowballing effect by having to work under everyone’s watch which might lead to even more bugs or such a delay that ruins everyone expectations of the project.

To avoid this tragic fate, we have to aware of the fact that releasing is just a step in the whole process of delivering a software product which forces everyone involved to be open and honest about project’s scope and what can be achieved in the allocated timeframe. A good side effect of this is that requirements also get trimmed down to the essential features required for the software to be useful and allows for a good understanding of the requirements as a whole which enables the team to build a solid base that can be built upon in the future.