Back to blog home

The benefits of feature flags and stubs in software development

A feature flag is a technique in software development that allows you to test a feature before it’s completed and ready for release. Here we explore how this technique, combined with method stubs, paves the way for faster, more efficient software development.

What is a feature flag?

A feature flag (also known as a feature toggle, switch, flipper, and conditional feature) is a technique that’s used to hide, enable, or disable features during run time, allowing you to switch-off some functionality in your application without having to deploy new code. 

It aims to provide an alternative option to maintaining multiple source-code branches (known as feature branches) and can be used during the development process to enable a feature for testing, while disabling it for other users.

What is a method stub?

A method stub (or, more simply, a ‘stub’) is software development code that’s used to stand in for other programming functionality.

A stub may simulate the behavior of existing code (such as a procedure on a remote machine) or be a temporary substitute for yet-to-be-developed code. Stubs are therefore most useful in porting, distributed computing as well as general software development and testing.

Wikipedia

The combined power of feature flags and stubs

Feature flags and stubs are powerful techniques when used in isolation, but using them in combination gives your team a powerful foundation for developing, testing, and deploying software. 

When used wisely, feature flags and method stubs will increase your application's reliability, shorten the time between production deployments, and help your frontend and backend teams to work in a more aligned way. 

Now let’s dig a bit deeper to see why this is the case!

Why (and how) to use feature flags

One and a half years ago my team decided to introduce a very basic feature flag module into our project which was built using the platform’s core features. 

Spending a few hours on the feature flag module certainly paid-off in the long term; it avoided a lot of trouble with micro-managing CVS and shortened the project's release cycle at the same time. But more importantly, changing functionality could be done in isolation – i.e. separately from deploying a release.

Just imagine a scenario where you have a huge promotion kicking-off to advertise your Next Big Feature. Without feature flags, someone will have to update the application on the very day of the promotion.

But by using a feature flag, you don’t have to worry about releasing the promoted features the same day as the start of the promotion. The code can be deployed into the live system beforehand, then the switch can be flicked on when the time comes.

What’s more, if the feature flag system is prepared to handle ‘exceptions’ for users (for example, when a feature is disabled for everyone except the QA team), then the promoted feature can be safely tested on the live environment, decreasing the risks.

Of course, just like everything, the technique of feature flags has its pros and cons. Depending on how the flags are set at a given time, new user journeys that weren’t there before could emerge. As a result, the QA team will probably need more and more time for testing as the number of flags grows. 

 

If you’ve only conducted manual acceptance testing up until this point, you should consider using an automated solution. Of course, you could still use the manual method while you only have a relatively small amount of flags to check, but introducing automation will definitely pay off in the longer term.

Having two runtime paths gives you the flexibility to go back to a working state of your application, without having to roll back your last deployment. Adding new functionality to a minimum viable product (MVP) is much smoother since you have a reliable solution you can revert to if needed. 

But maintaining two runtime paths will of course require maintenance in the future. As time goes by, you could end up with long-unchanged flags, features rarely used, or things that are simply no longer required as business requirements change. 

That’s why, if you’re using feature flags, you’ll want to regularly revisit and clean-up code to remove anything that’s no longer needed.

How to quick start with feature flags

A feature flag module for your application can be built fairly quickly, or even from scratch, by re-using existing platform features or using a platform-as-a-service (PaaS) solution. 

PaaS feature flag services will give you more fine-grain control over the functionality, and you can even do A/B or canary testing. Combining a PaaS solution with analytics is a compelling tool for increasing revenue through gaining insight into how conversion differs across different customer journeys.

The next thing you’ll need to define are the conditions, which will decide the user journeys (for example, if flag A is on => journey A, flag A+B => journey B, otherwise journey C). Then you’ll need to identify the earliest ‘entry points’ in your application where the business logic will start to differ.

Why (and how) to use stubs

So how can stubs help to further streamline your software development? 

Imagine having a large body of work or epic that builds on top of a complex, external API that handles the backend data. This work is going to require a lot of frontend development, but the backend implementation hinges on the external API and could be hindered or slowed down due to reasons (that are out of your control) with that third party. As a result, your frontenders could quickly became blocked until the API is implemented. 

The good news is that stubs can essentially replace the real API so that development isn’t held up. For example, your domain layer could return a canned response in response to a data request from the backend. This unblocks your frontend (and maybe also backend) team. And later on, those canned responses can be replaced by real data from the external API. 

But you can also add stub behaviour into lower levels in your application, for example by abstracting and replacing the communication layer. This way a specific application state can be set up that makes CI tests more reliable, for example. 

What’s more, by making stubs configurable it’s possible to pre-set almost any real-life scenario, even cases that may otherwise be hard to reproduce. Testing network failures between subsequential API calls can be hard. But you can configure your stub to break every second API call.

There are many other scenarios where configurable stubs can help, and they can often act as a stand-in replacement for systems that are hard to manage – for example, if a service takes too much time to produce a response, if its state has to be to manually restored after a test, or if it does something that’s impossible to revoke. 

Having a low-level stub can also be of a huge benefit when you need to replicate a production issue. Using it this way requires a certain level of abstraction in your application, so it can be changed with the real implementation – transparently – any time. 

 

Using feature flags and stubs in combination

These two techniques can be used separately, but feature flags and stubs can support each other very effectively. Together they enable your team to be more agile as requirements change, with the ability to leave that unfinished feature in your code, but keep it switched off for now.

Stubs will help with quickly unblocking developers (for example, an API for an external service is not yet ready) by removing blockers. Re-using and adding more behaviour to your stubs will also help you in later phases of your project when it comes to business-as-usual (BAU), where stubs can be reused for debugging purposes. 

You could also partially stub something to reproduce infrequent behaviours in your application – such as mimicking a network failure. These two techniques will also help you to introduce continuous deployment more easily on your project, since an unfinished feature (which may still be using stubs) won't block your team from frequently deploying code to production. 

Get started with feature flags and stubs

So now it’s over to you! If you’re interested in trying out these two techniques in your software development, start by sharing your knowledge of the benefits of feature flags and stubs with your project team. As part of this education piece you might want to try a small feature with a feature flag to see how it works.

Remember that the stub technique can be introduced anytime to help remove potential blockers during development, so it’s never too late to get started. As this post as hopefully highlighted, these techniques are really not rocket science; all that’s required is a little more attention to detail and planning. Enjoy!

Digital strategy consulting

Our award-winning web and software engineers are enabling businesses to solve their most complex technological challenges. So whether you’re looking to automate business processes, upskill your teams, or deliver better experiences, we can help.

Related reading