Slowing Down the Release Cycle

I’ve been working in IT in various roles for more than 12 years, and I witnessed and experienced how release cycles became faster and faster over time. Seeing recent (and not so recent) trends in competitiveness, degradation of attention span, advertisement of short-term satisfaction, etc., I wonder where this increase in speed will lead in terms of software quality, end-user experience and satisfaction, engineer burnout, and whether it is possible to slow down a little.

What Do We Want? Anything! When Do We Want It? Yesterday!

Two things come to my mind regarding this topic: shortened attention span and the want for short-term perceived satisfaction.

I hear people complain about a shortened attention span, which is due to many various factors like social media (see products like TikTok, YouTube Shorts, and many others), and I feel as if more and more products pop up that promote and worsen this.

At the same time, I also see people wanting and promoting short-term or immediate satisfaction, be it anything really. With online purchases, same-day shipping, online trading, 30-40 year mortgages to get that house now, and more, people nowadays want everything, and they want it yesterday. Long-term planning and long-term satisfaction are becoming less of a thing, and that is, to a degree, mirrored by the IT sector as well.

Drawing a parallel with software releases: nowadays, continuous delivery and deployment are very prominent along with containerization, and with all that automation, production deployments can happen every hour, every 30 minutes, or even less. Although it is definitely a good thing for deploying bug fixes or security fixes, I wonder how much benefit it really has when it comes to deploying features and feature improvements.

Is the new code deployed actually benefit your end-users (whether it's for competing with another company or not), benefit the company's engineers for improving/laying the foundation for further development (I see no problem with this), or is it just due to a perceived/false urgency coming from higher-ups, or from the general state of the current digital market, to "compete" with others.

Does One Actually Know What They Want?

In childhood, we are taught (ideally) that we don't necessarily get everything we want, and not necessarily when we want it, but we have to work hard for many things, and the results and success will materialize sometime in the future, and as periodic little successes along the way.

I separate wants into two categories: whether your customers know what they want and whether you or your company know what your customers want.

As for the earlier: when your customers are satisfied with your product, that is awesome. But when you always give them everything they want, and/or immediately, you might end up with cases like this: it is a problem that a certain video game is not released in time, but it is also a problem if released in time due to pressure, with questionable quality. So, they don't even necessarily know what they want. (If you are a Hungarian reader, you might be familiar with the song called Az a baj from Bëlga).

As for the latter, at least in the world of outsourcing, though, there is a distinction: the client pays you for delivering what they want to their customers, but your children don't. Clients might leave like an offended child (and might never come back) if they don't get what they want when they want it, even if that thing is unrealistic or, even more, not so legal. But that is something that can be shaped by great managers, Project Owners, Business Analysts, etc.

On the Topic of Analytics

It is one thing that end-users, like when in a candy store, don't necessarily know what they want. But do companies themselves actually know what their customers want, or do they just throw things at the wall, hoping that something would stick?

Companies can get their hands on so much analytics data that it's not an easy feat to process it, organize it, and actually do something with it. If companies don't have the (right) people, or they burn out and leave, they would have no proper clue of what their customers want and in what way.

This isn't helped by the fact that, in some cases, there may be a large amount of inconclusive or contradictory information on how certain features are received by customers. Take, for example, one of my previous projects: there were several hundreds of active multi-variant tests running on the site, in many cases with 5, 6, or more variants, at the same time, along with tens of active SiteSpect tests in the same area. How you draw conclusive results from them regarding customer conversion rate and what works for your users is magic to me.

These all can result in potentially premature decision-making and can lead to uncertainty.

What About Slowing Down?

It may be a good idea to consider taking a step back, getting some perspective on how your project operates, and slowing down the release cadence a little.

Whether it is better care for your customers and your project members, or you just want the project to get more money from users, releasing less frequently may be a good idea... if you can reallocate time, money, and effort properly.

I know slowing down the release cadence is not applicable to all domains and projects, and it might be suitable differently for small, big, open-source, greenfield, startup, commercial, etc. type projects. But the option is still there, and it doesn't hurt to think about its potential benefits.

A Personal Example

I personally develop plugins for JetBrains IDEs, and I like to bulk-release new features and improvements. It gives me more time and headspace to come up with ideas to further polish features so users can also get a better version of them right away instead of getting them in chunks. This also produces less technical-/feature-debt for me and less paperwork, e.g., for tracking and maintaining issues on GitHub.

It also saves me time because I have to go through the release process less frequently. I produce fewer release-related artifacts over time compared to, for example, releasing each new feature individually. And it produces fewer plugin update cycles for IDE users as well. However, when it comes to important or critical bug fixes, I do release them quickly.

Question Time

I know it can work quite differently for companies with hundreds of engineers finishing features and code changes each day and wanting to release those features in the wild soon after they have finished. But, even in that case, it might be a good idea to slow down a bit. It kind of reminds me of publishing music: you can either drop a hit single now and then and then later wrap it and call it an "album," or you can work on a bigger theme for a while and publish them at once as a real album.

I also realize in regulated domains, frequent and fast releases are required to keep up with regulations and legal matters. (I still remember when the cookie policy and GDPR had dropped.)

Now, let me pose a few questions you might want to explore deeper:

• What if you would release less frequently? Do you need a release every minute/hour/day? Would a one-week/two-week/one-month/... cadence be better suited for your project?
• Would it make sense for your domain and project?
• Do you actually have the option to do so?
• What advantages and disadvantages would it have on your engineering and testing teams' mental health?
  • Would they feel more ownership of the features they develop?
  • If you have manual testing for each release, would less frequent releases have a positive effect on your testing team? Would they have more time to focus on less tedious tasks? Would they have more time to migrate manual test cases to automated ones?
  • What effect would it have on your end-users/customers' satisfaction? On your customers' conversion rate? On your infrastructure and code/feature quality? On your business in terms of customer retention, income, and growth?
  • If you are in a cloud infrastructure, would less frequent deployments lower the costs of operation?

Let me also get a little deeper into two specific items from this list that I have had experience with before.

Feeling Ownership of the Product

I'm sure you've been in a situation, or at least heard someone, after finishing a bigger feature, say something like, "We could also do this and this!", "We should also add this!" and their variations. When you don't have the time to enjoy what you've accomplished, and you are instantly thinking about the next steps, it's difficult to feel ownership of the feature you've just finished.

If engineers had the option to work longer on a feature and release it in a better state in fewer releases, I think that feeling of ownership and accomplishment could become stronger. (Unless you cannot relate to the feature or the whole domain at all for any reason.)

On a related note, I recommend you watch the YouTube video called Running a Marathon, one mile every hour from Beau Miles, from which my favorite quote is, "Been meaning to do this for two years. 10-minute job."

Manual Release Regression

Years ago, I was on a project in the hotel accommodation domain, on which the website we developed was also used as a platform so other companies could pay our project's company to create branded websites for them.

The creation and configuration of these sites were handled by a dedicated team, but testing affected many other teams. Almost every two weeks, we received an email from that team asking us if we would be kind enough to "do a slight regression" (automated and manual) in our area on those (up to ~20) new branded sites and/or points of sale.

I know that the site creation was an on-demand process, and it was necessary to serve those customers quickly. That is fine. However, many people would have benefited if those manual regressions occurred, e.g., only once in a month instead of bi-weekly. Even with a bigger scope and workload, it would have required less effort from our team (context switching, reorganizing sprint activities, communication overhead, etc.), especially since there wasn't always a heads-up about when we would have had to do it. Thus, not much planning could have happened beforehand.

Closing Thoughts

There could have been many more aspects mentioned and taken into account, but covering every aspect of this topic was not the intention of this article.

Hopefully, you leave with some of these questions and ideas, making you think about how to answer them or apply them to your projects.

This article came to life with the help of Zoltán Limpek. I appreciate your feedback and help.