Why shipping regular updates is good for your development process and more
When you’re developing apps, at some point you need to release updates to your users. There are benefits to releasing updates frequently, but there are lots of factors that make it hard to do.
In this article, I’ll explain why it’s good to make regular releases, what can get in the way of doing that, and outline some strategies that you could use on your project to help you get your releases out more regularly.
Why It’s good to release updates frequently
Users like new features
Users want to see new features, improvements, and bug fixes — particularly if they’ve paid for the app or a subscription to it. Releasing regularly shows users that the app is valuable and evolving.
However, there’s a caveat to this. Moving features around and changing behaviour can be confusing and harm your app’s user experience, so it’s important to manage how change is released. Little and often is a good way to go.
Small releases are less risky
The smaller the release, the smaller the risk of releasing.
Say you’re releasing one feature. Despite all the preparation you have done, there is a serious bug. Whilst this isn’t ideal, it’s manageable. You fix the bug and you update it, and your broken app is on the app store for a minimal amount of time.
Now imagine you release ten features at once, and you manage to introduce ten serious bugs. If that actually happens, you probably have more to worry about than your release strategy, but it illustrates the point. You would be in a bad situation, trying to fix ten serious bugs and get an update out as soon as possible. To minimise your risk, keep your releases smaller and more frequent.
Delivering value
In agile software development, we often talk about the importance of delivering value. What that means is getting the end result of expensive development hours out to users as soon as you can, rather than storing them up in unreleased repositories. The longer software remains unreleased, the more likely it is that it will degrade and require further work before being released, or, worse still, that it will never be released at all.
What Gets in the Way of Releasing
You might aspire to releasing updates frequently, but it can still be difficult. Understanding the factors that prevent you from doing so is the first step to getting a successful strategy in place. Here are some of the most common scenarios.
Just one more feature
Release creep is a common trap that’s easy to fall into. You’re almost ready to release, and someone says, “feature x is nearly ready, can we just get that in as well.” And when feature x is done, you may as well wait for feature y. The problem is there’s always another feature on its way — your release gets bigger, and the time since your last release gets longer.
Tips for avoiding release creep:
- Plan what’s going into your next release upfront, and stick to your plan.
- Keep releases small and frequent, so if a feature has to wait until the next release it won’t be too long.
External dependencies
External dependencies can easily block releases.
Consider a new feature in the app that requires a change to a backend API. Let’s say you’ve added the feature to your code, but the new API hasn’t been released yet. If your app doesn’t work without that API feature, you’re now in a position where you can’t release an update. This also blocks the release of subsequent features and makes it much harder to release emergency fixes.
This is surprisingly common in practice. I’ve seen commercial app projects that have spent months building an app, only to have to delay the release of the app by months, or even years, because required external dependencies weren’t completed.
Tips for avoiding delays due to external dependencies:
- Avoid starting work on features until external dependencies are available in your production environment.
- If you can’t guarantee external dependencies being available, use feature switches to hide features from users until the external dependencies are available.
Unfinished features
You can’t release if your code contains features that aren’t ready for users to see. Maybe the UI isn’t finished, or it hasn’t been fully tested or approved for release. This can be more of an issue if you’re working in a team because it can be hard to line up multiple features to be finished at the same time. And if the code isn’t in a state to release, it can be tempting to start a new feature while the other one is being finished, and before you know it, you’ve got release creep.
Tips for managing unfinished features:
- Plan which features are going into your release in advance. Once they are complete, don’t start any more until your release is done. It can help if team members a pair on any remaining work to get the release over the line.
- Don’t start a new feature until the last thing you were doing is finished, tested, approved, and ready to release.
- Plan your work into small, deliverable chunks that can be released independently to users.
- Consider using feature switches to allow work to be included in your codebase without being visible to users.
Releasing takes time and effort
When you release an app to the app store, there are various processes that you need to complete. You’ll need to test your app, archive it, upload it to the store, prepare the store page with marketing information and screenshots, put your app through review, and finally release it to end-users. While many of these steps can be automated, there almost always has to be some level of manual intervention. If your release takes too much effort, you’ll be reluctant to do it frequently.
Tips for making your release easier:
- Automate as much of your release process as you can. If you can test, archive, create screenshots, and upload to the store at the touch of a button (or a merge to master), you can remove much of the pain of releasing.
- For anything you can’t automate, create a checklist or a process you can work through quickly and repeatably.
The compounding effect
If you’re in a position where something is stopping you from releasing, it’s easy to end up in a feedback loop. The longer you leave it, the riskier it gets, the more you are affected by external dependencies, and the more time and effort it will take when you finally do release.
Strategies for Releasing Your App
If you’re struggling to release, I recommend you take stock, take a look at what factors are impacting you, and select a strategy to make things easier. Here are some of my favourite strategies for releasing mobile apps.
Release after every feature
This strategy gives the most frequent releases. As the title suggests, every time you complete a feature, you release your app to your end-users. This strategy is good because your users get change little and often, it’s easy to test, it’s low risk, and it delivers value to your users as quickly as possible.
However, if you have more than one or two people in your team, it can be a difficult strategy to manage. You need to ensure that your code is always fully tested and releasable, and the overhead associated with each release can quickly become expensive.
This strategy works well for:
- Single-person teams and hobby projects.
- Releases that are highly automated.
Batched releases
This is a simple strategy, where you decide when you have enough features to release. You can either plan this in advance, or decide on an ad hoc basis. Once the features are completed, you make the release.
This can be a good strategy because it’s flexible, lightweight, and doesn’t require a lot of processes.
However, whilst this is the simplest strategy on paper, it’s probably the hardest to get right. It’s easy to fall into the feature creep trap, and it requires good discipline to stop releases getting too big. It can be hard to get your code in a releasable state, with everyone in the team lining up finished features together. It’s particularly difficult to make this work if the team is new or not working well together, or if there are low levels of trust within the team. Teams often default to this way of working, but I wouldn’t recommend it unless you have a strong team and you apply the strategy intentionally.
This strategy works well for:
- Small to medium teams.
- Teams with good delivery discipline.
- Teams with a high level of trust.
Scrum
Rather than being a release strategy per se, this is an entire delivery framework. In scrum, teams work in sprints. These are regular, time-boxed intervals, typically around 2–4 weeks. The features to be delivered are agreed upfront, and released at the end of the sprint. In practice, this is very similar to batched releases, but the framework provides more structure and process to help you get releases out.
This strategy is good for getting a managed amount of change out to users at regular intervals. It makes it easy to ensure the code is releasable when it needs to be, and it stops your releases from getting too large. It’s great for developing good delivery discipline, for example in teams that are new or aren’t working well together. And because it sets out expectations and commitments to meet those expectations, it’s good for building trust within teams.
On the downside, scrum introduces heavyweight processes and ways of working that can slow you down, so I wouldn’t recommend it for teams that are already working well, or where there isn’t a problem that needs fixing.
This strategy works well for:
- Teams that are struggling to release.
- Teams that don’t yet have a good delivery rhythm.
- Teams with lower levels of trust.
“Release train“
The term “release train” was coined by Spotify in their Spotify engineering culture presentations and it refers to making releases at regular intervals, regardless of what work has been done. The metaphor is that the release train leaves the station at regular intervals. Features that are ready, make the train, i.e. they go in the release and are released to users. Features that aren’t ready miss the train and wait for the next one.
This strategy is good for establishing releases at regular intervals. Change is released in small batches, at a manageable frequency. It is good for demonstrating progress and delivers value to users regularly.
The downside is that you need a good way of managing features that aren’t ready for release, for example, feature switches. This introduces a lot of complexity and management. In bigger teams this is well worth the cost and effort, but in smaller teams I’d recommend thinking carefully before introducing it.
This strategy works well for:
- Medium to large teams.
- Projects with good levels of automation.
- Well established teams with strong processes.
- Projects where you want to make frequent and regular releases.
Summary
In this article, I described why it’s good to make frequent updates to your app, and what can stop you from doing that. Then I outlined some of my favourite strategies for releasing mobile apps. Thanks for reading, I hope you found it useful.
Read more
Gabrielle Earnshaw is a Principal Consultant at Infinity Works.
Read more by Gabrielle Earnshaw on her Medium blog.
