What the F**ture?!

We are fortunate enough to work in a cosy world of a component-based architecture. Several of my colleagues have a love of microservices, and none of those are afraid to shout it proudly from the rooftops. Our approach introduces a lot of benefits ranging from the obvious such as decoupling of key logic, to flexibility of hosting.

 

 

Developers need to be as comfortable switching features off as they are with a light switch

 

Multiple teams owning these components introduces some challenges. When things don’t go to plan, a single team can block itself and others if that new shiny logic is not ready. I’ve witnessed more than one instance recently where toggling the feature off would have prevented the ensuing frustration of features being blocked. Unexpected behaviour with features in production would also have benefited from a feature flipper. Here I reflect on recent issues on encouraging feature flag use, in the hope we can learn to love the off switch.

 

Capture the Flag

 

People are scared of being found out, especially when they don’t know something. It takes a lot of nerve to admit lack of familiarity in a world where knowledge is power. Even the most humble of egos doesn’t want to get caught in the trap. I have many developers not using toggles that when approached in a more comfortable environment will admit they don’t know what they actually are.

 

I’m not just talking about naming here. As outlined by Pete Hodgson and Martin Fowler, there are several different names in use. However, a rose by any other name still smells as sweet. The problem is that programmers believe that the implementation is fundamentally different depending on their usage of framework X or technology Y.

 

 

 

Be comfortable that surrendering to feature flags does not make your code any less elegant

 

 

Developers think we need to have an all singing, all dancing framework that can turn functionality on and off. I’ve seen examples of how to build such toggles on both the client and server code. I advise that under the KISS principle, the simplest approach is always best. To that end, a simple constant controlling an if statement is suitable for the majority of use cases. If this can be parameterized to be passed into the process to permit switching the logic off in production with a config change rather than deploying a new code version, all the better!

 

It’s Complicated

 

It’s not simply the case that once developers know what a feature toggle is and how they can be constructed that they will immediately be sold on using them . I’ve heard quite a few attempt to justify not writing feature toggles. Developers and leads alike regularly attest that they don’t need toggles, for differing reasons.

 

The first, is their effect on code complexity. Those of us from a Computer Science background will remember back to that first lecture on complexity. Perhaps several algorithms were scrawled in messy lecturer script on the blackboard, with the class tasked with determining their complexity. Those of a different discipline will have picked it up from general reading or training.

 

Regardless of where that spark of knowledge came from, we have answered enough exam questions and provided enough interview answers over time to be able to explicitly calculate complexity with ease. It implicitly forms our decisions on algorithm design and coding on a daily basis. For some, it is used as a justification for not adding a feature toggle. That is certainly not the case if we remember back to our complexity rules.

 

Algorithm elegance doesn’t justify a lack of toggles. Part of this stubbornness could boil down to a misunderstanding of the permanence of a toggle. No one is suggesting that toggling code should be permanent. Good developers will remove existing toggles once the logic is verified in production. Great engineers will add and remove them consistently to their features. Leads need to support these engineers in their introduction for new features and logic changes alike.

 

So Much for My Happy Ending

 

The perpetual optimism of developers is another challenge in the adoption of feature toggles. No one wants to think that building out the latest story will go anything but smoothly. Engineers will blindly follow the yellow brick road all the way to Oz. They will typically have at least one or more of the below mindsets:

 

1. My feature will definitely go live! I will not encounter any blockers along the way.
2. I’ve comfortable with the code base so it will definitely take me X days to implement this story.
3. This new feature will definitely work first time. My code is perfect, bug free and I’ve covered every edge case with my tests.

 

Each of these arguments can be used by developers as an attempt to discount building a feature toggle. Programmers are human, and optimists at that. We all want to feel the warm glow of our work being used by clients. Nevertheless, with this optimism comes the notion that we will deliver perfect features, on time, every time. Turning that feature off suggests that all the blood, sweat and tears they poured into development will be in vain.

 

It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.

Jeff Patton and Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product

 

We need to nurture faith that there are benefits to hitting the off button. The benefit is that we have flexibility to cover when things go wrong. It’s alright for development work to run over, to be incomplete, and that turning it off and on is a good thing. Foster some humility in your developers to get them comfortable switching their features on and off. An initial leap is satisfying for individuals, but it’s not always the right call for the collective.

 

Thanks for reading!