It seems almost passé to say that the healthcare industry is risk averse. Healthcare workers are increasingly time-pressed as they attempt to provide day-to-day patient care to an expanding number of people. Stress rises when a new system or method is forced on them. As a result IT innovators sprinkled throughout healthcare organizations who build new software systems find it difficult to release and gain adoption of their innovations.

Users’ resistance to change can lead to a fear of change that manifests in an IT organization as well. This fear is well founded. Many healthcare organizations have a history of projects gone awry and are afraid of consequences such as user adoption issues, bug mitigation, and the tumult that comes with branching code.

What users actually hate is change that makes things worse.

1. User Adoption Issues

A common myth is that users hate change. However, if people hate change most Silicon Valley companies would be out of business. (Who needs a computer when you have a typewriter?) In fact, users don’t hate change. What users actually hate is change that makes things worse (e.g. common EHR user interfaces). Users are more open to adopting change that might improve their lives when they perceive the value of that change.

2. Bug Mitigation

The software industry as a whole continues to suffer from unstable code. Many disciplined software development shops follow test driven development, which greatly stabilizes the code base. Unfortunately, healthcare development teams have been slow to adopt this practice. This leads to a legitimate fear that when the system is deployed, users will find problems and updates will need to be rolled back. The pains of a botched deployment seem greater than the gains of new features, so the deployment is continually held up for more and more testing.

3. Code Branching

Major features of a project often take weeks or even months to develop. While the team works on the major feature, minor enhancements may be introduced as well. To accommodate this parallel effort, a team may decide to branch the code and merge the features at a later time. Unfortunately, code branching has a number downsides: increased overhead, dilution of effort, and diminished productivity of the development team.

Fortunately, there are solutions to overcome the fears of user adoption issues, bug mitigation, and code branching. One solution is the Feature Toggle, popularized by Martin Fowler in 2010, is a programming technique that can be used to mitigate these fears. Think of the Feature Toggle as the programming equivalent of a set of checkboxes that will turn features on or off within an application. This simple technique can be implemented with a configuration file that defines the on/off switches (toggles) for pending features. As the application executes, the available features are determined based on the value of each toggle.

The features can even be toggled throughout deployment. For example a feature can be turned on in a development environment, and turned off in staging and production. In this way, feature sets can be tested differently throughout the release process. When the feature is ready for production, it can be turned on by changing the configuration file rather than requiring a full deployment.

There are three great reasons to use feature toggles to mitigate the fears that come with deployment:

1. Phased Deployment

If there are any problems with the system (latency, data, etc.), users will have a poor experience, and be less excited about adopting the feature. As mentioned earlier, Feature Toggles allow you to roll out features to groups of users, as well as support phased deployments to Development, Staging, and Production. A phased deployment approach limits the exposure of a failed deployment, and gives the development team the confidence needed to proceed with a larger deployment.

2. Quick Access Control

One fear that plagues Health IT organizations is that new deployments will have many issues and will need to be rolled back. With this rollback can come related hassles of database changes, user access being shutdown during work hours, and the perception that the release engineers are incompetent. New features are typically accessed through the user-interface of the application. With a feature toggle, the new feature can be quickly turned off and allow users to get back to work with minimal downtime. This facilitates a planned remediation effort rather than responding to the demands of the moment.

3. Minimal Code Branching

Imagine your development teams have the capability to release into production every two weeks, but need to build a feature that is going to take three months to complete. By intelligently incorporating feature toggles the team can use Continuous Integration to keep everyone working on the mainline branch without revealing half-implemented features as new releases get pushed out. A configuration file can define a set of toggles for pending features. The running application consumes these toggles in order to decide whether or not to enable the new feature.

For your next software development project, encourage the team to incorporate Feature Toggles into their code base. This will help them reduce the fear that comes with deployment, increase end user adoption, and facilitate the reduction of code branching.