When should we ship?

Published on Thu Jan 02 2020

Question: What software is the most valuable?
Answer: The software that actually gets released!

This small statement is obviously a funny punch towards long running software development projects that ends up never getting shipped – I guess it is born out of the agile movement (though I’m in no way sure).

For the sake of this article I am assuming that we are talking about SaaS when we talk about software.

You must release

Keeping in mind that your software will receive a bump in value when released it is very important that you actually get it out and into the hands of some actual users.

But now that we are in aggreement about the need to release – when should we do it??

Impact upon release

There are many factors that you must take into account when releasing. The impact on the users will definetely have a say in what you choose. So what are the factors that actually affect the users?


I assume that your software will have some downtime when you deploy. There are some ways to have zero downtime but this should be taken with a grain of salt. For the case we assume that there is actually some downtime.

Even though the downtime mught be just a small glimpse it might affect your users or any use of your software generally.

This must lead to the conclusion to not roll out a new version when the system if actively in use. This might be a challenge with software that is used all over the globe in many different timezones.

It also might post a challenge because there might need to be actual people performing the upgrade – and that means that some 9-5 workers will need to be at the office – an obvious conflict with making deployments outside normal working hours.

Things are going wrong

There might be things going on, when deploying, that can go wrong. On top of mind are things like database schema migration and new configuration. This might lead to a larger-than-planned downtime which will affect users.

This highlights the importance that upgrades should be supervised and not left to automation – of course there are upgrades (most might be like this) that doesn’t change anything dramatically – but even the smallest deployments might go wrong (depending on your setup and deployment system).

Changes in features

Changes in featureset won’t necessarily be a part of a given release but they impact the users when they are. Depending on the user base they might take small and even large changes to the feature set less than well. Many user segments respond to new features (or cutting exsisting features) with almost disgust – they just want things to stay the same as they’ve always been because they are fine.

When developing new features you should have a clear goal who should use them which in many cases will come down to specifying if the new features are filling a gap for exsisting users or made to acquire new users – regardless the information surrounding the release should be clear and to-the-point about this.

Changes in UI

Changes in the user interface might be the only thing that can anger users more than changes in features or downtime. Changing colours, buttons and placement of these, or even bigger re-arrangements might actually confuse users to the point there they can’t even focus on using the software anymore. It might anger them to the point where they actually quit using your software. And this isn’t based on anything rational – the changes you’ve made to the UI might even be praised be every UI expert on the planet as the best change ever – but all your user(s) can think is “I liked that button better in green and on the left side of the text”.

Make sure to take this into account when releasing – changes in the UI might seem small but they needs to be documentet as well as new features – and they impact the users as much.

Picking a day

The week has seven days. Everybody has an opinion on when releases should and should not be made. Let’s go through the days:

  • Monday – the start of the week. Could be a good day to release, but everybody could have a bad case of the mondays and deliver a bad product. This also means that crunch might be during the weekend to get everything ready in time for monday release.
  • Tuesday – this leaves one (normal working) day for preparing the release – but this is monday – and depending on how the team handle mondays this might not be enough.
  • Thursdag – at this point everybody is already getting ready for weekend. If something brakes on thursdags it only leaves friday to fix it and if that isn’t enough weekend crunch is upon us.
  • Freday – everybody is saying that friday releases should be avoided. This is because something will eventually go wrong and with a team already headed for a deserved weekend break you have a bad cocktail at your hands.


As you might’ve noticed I (intentionally) left out wednesday!

Balancing all the above wednesdays might be the best alternative if you absolutely have to pick a release day. It is far enough from the weekend to allow any missing pieces to be put together without having to enforce weekend crunch. It also allows any mistakes to be fixed without having to press working hours into the next weekend. Everybody on the team should love this.


At ABC Softwork we release on wednesdays – as a rule of thumb. We ship bug fixes when they are done.

But that doesn’t cover when you should release.

I would argue that all of these issues that might arise can be mitigated by a solid well tested release procedure with the ability to perform roll backs automatically. This might not always be something that is realisticly achieved.

I’d recommend constantly improving and refining the release and deployment process towards full automation while keeping a close eye on every release (no matter how automatic).

The most important thing to avoid and/or document is the impact on the users – as most of this is expected it can be thought of in advance and users can be well prepared. Everything should be measured with regards to user impact.