Software feature flagging for dummies
Software is changing, fast. In fact, the software on your desktop, laptop, mobile and embedded Internet of Things (IoT) devices is changing faster than at any other time in the past.
This phenomenon of sorts has been brought about by the existence of connected cloud computing services, the ubiquity of mobile devices and by the very existence of the web itself, which of course acts as an interconnecting conduit and platform for wider coalescence.
Software used to be a comparatively static thing, supplied on a disk of some form or other. In the new age of the mobile cloud-connected web, a user’s software can be potentially updated anywhere, anytime and at any time.
Software is now continuous
This has led the software industry to coin a couple of new terms. Continuous Integration (CI) & Continuous Delivery (CD) are among two of the biggest driving forces in the industry. Both are used to express the fact that software updates can come thick and fast on a regular basis.
The software updates themselves (on your smartphone or tablet perhaps) might appear to be being sent continuously, but that’s not why we use the term. The continuous factor expresses the fact that the software itself is continuously updated with, usually while a ‘live user base’ of individuals are using an application and its ancillary services.
So where does all this get us to? The answer is found in two words: new features.
The reason we are being continuous is that users continuously want new features, software vendors continuously want to show us that they can innovate and provide ‘cutting edge’ applications and services and, at a higher level, the application of technology is changing all the time so there is a continuously changing and dynamic need to do something different.
YOU MIGHT LIKE
Why your next software is a ‘guided template’
Where all this gets us to is the process through which new features are delivered— and there are two key methods.
After a period of internal trials and User Acceptance Testing (UAT), software vendors can roll out updates to every user and see what sticks.
Essentially also a UAT method, but perhaps more managed and granular is the practice of feature flagging.
Feature flagging is an element of software feature management that makes use of so-called flags and toggles, which decouple new features from the main software code base release. Individual test users (yes, it could be you) are then targeted to try out new features using a system of targeting rules, so that only those users will be able to see use that new feature exists.
Flags alert users that a new feature has been added, switches and toggles (sometimes also called switches, flippers, or conditional features) turn that feature on or off so new features can be rapidly disabled if they meet with poor reception.
Balancing caveats & cautions
Is feature flagging all good news? Yes, it’s good that it’s here, but no, there are downsides.
Usually managed through the DevOps (developers + operations) team’s controls, good feature flagging can put new functions in the hands of business users who have often asked for their organization’s software to be changed, so that they can help test it out prior to wider deployment.
Bad feature flagging can lead to technical debt with chunks of rogue code left festering around the enterprise. It can also lead to software sprawls and software forks where one department uses one version of your core software applications, and another uses another.
In total, we can be sure that business users may very well find themselves involved in feature flagging exercise, but these processes themselves need to be tightly managed, ideally short term and always carried out with a holistic view of the entire enterprise’s IT stack.