There’s a certain key moment in every developer’s career. Okay, there are a lot of key moments. But I’m talking now about the one where you first really understand the concept of technical debt. Even if you don’t know the term “technical debt” when it happens, you’ll know the feeling.
A project manager comes by your desk and starts to describe a feature he wants for an upcoming release. As he describes it, you start to get a sinking feeling. “That means I’ll have to heavily edit the dreaded session management code,” you think, as he whiteboards things out for you. He then asks for a ballpark estimate of the effort it will take on your part. You manage to buy yourself time by telling him that you need a day or so to investigate, but you already know things are going to get ugly.
Why? Well, because what he’s asking for seems easy. It should be easy. All he wants you to do is add a form to the order screen that shows the user her basic account information. The project manager probably expects this to take an afternoon of your time or, worst case, up to a week.
But you know otherwise. It’ll probably take you more than a month to completely rework how sessions are handled throughout the entire application. You’ll try to explain this rationally with a diagram of your architecture. But you’ll feel (and look) ridiculous as you do so.
Technical Debt: The Software Developer’s Eternal Headache
What I’ve described here is one of the most obvious and classic symptoms of technical debt. Specifically, things that seem easy wind up being weirdly hard. When that happens, it chips away at your credibility and reputations as a professional. Imagine hiring someone to fix a clogged drain only for him to tell you that it’d take a week of 12 hour days. No matter how emphatically he white-boarded the problem, your gut would tell you that he was a charlatan and that you should get a second opinion.
Ward Cunningham, creator of wikis and signatory of the so-called “Agile Manifesto,” first coined the term technical debt in the early 1990s. He used financial debt as a metaphor to demonstrate that developers could take shortcuts to satisfy immediate business demands but with the caveat that payment would come due with interest. In other words, there’s no free lunch.
That metaphor has flourished, since it so aptly demonstrates the trade-off. A software developer throws a global variable in her code as a shortcut to allow the business to ship. But she also cautions that, during the start of development of the next release, they must go back and do it right. They’ll need to pay that debt and pay it with interest, since they’ll spend time undoing the hasty approach and implementing the correct one.
But developers often forget to pay the tab, or else managers don’t give them time. In either case, technical debt often mounts in the codebase. Eventually it reaches crippling proportions, leading to scenarios like I described above.
Feature Flags to Help with Technical Debt
You have many options to help you manage and minimize tech debt. You have so many, in fact, that I won’t even begin to address them all here. Instead, I’ll talk specifically about the idea of feature flags as an aid with technical debt.
While feature flagging might not pop immediately to front of your mind as a technical debt mitigation strategy, it can help. You see, one of the most reliable sources for manufacturing tech debt comes in the form of release pressure. The business absolutely has to get some release out the door, and management doesn’t care if you have to stitch the software together with duct tape and baling wire. That release WILL ship.
Feature flags provide a release valve for this pressure. In the first place, they let you ship with reduced risk, since you can always turn off an offending feature. Combined with a sophisticated deployment pipeline, they also let you deploy at the granularity of feature instead of your entire application. This allows you to deliver value to the user base more regularly, making some concessions and horse trading possible. “We can’t get you the new admin module just yet, but we can deliver the product page enhancements.”
With this added release flexibility, you face less pressure to make poor decisions. This, in turn, makes you less likely to have to explain why something will take months instead of days.
Feature Flags as Technical Debt
All that being said, it’s hard to get around the fact that feature flags also introduce technical debt. Yes, even as they help you mitigate it in all other areas, they have their own cost.
This should make sense on a conceptual level to any software developer reading. If you take your business logic or markup and add “if turned on” conditionals everywhere, the code gets more complex. Now you’re managing both your application logic and a bunch of logic about what you should show, when, and to whom.
Of course, this doesn’t mean you should avoid feature flagging. Quite the contrary. To understand why, consider role-based application security. That also comes with a cost, introducing its own form of debt. But you wouldn’t find people arguing that you should scrap authentication because it can make your code more complex. Instead, you manage the complexity.
Feature flagging falls into the same boat. You cannot forgo the flexibility this gives your organization, so you need to find ways to manage it.
Enter Feature Flag Management Systems
To help with this, companies offer feature flag management systems. This emerged in response to haphazard, home-grown feature flagging that racked up mountains of technical debt. Over the years, enough nightmare scenarios emerged, with dozens of configuration files, if-riddled source code, and haphazard and inconsistent flagging logic, that vendors stepped in to solve the problem.
Feature flag management systems let you get intentional and consistent about your approach to feature flagging. This alone helps tip the scales, letting them save you more in tech debt than feature flagging itself costs. They solve the mysteries of how to add flagging logic, where to put the configuration files, and even how to manage them from a dashboard for your environments. They also have the added benefit that your team doesn’t waste time creating (probably inferior) homegrown ones.
Getting the Most Out of the Feature Flag Management System
With a feature flag management system in place, you can go even further to alleviating other sources of tech debt while keeping any created by your feature flags to a minimum. Just installing the management system brings you consistency and clarity. But you can do plenty on your end as well.
Trod well-worn paths to good code. Feature flags represent just another incarnation of cross-cutting, conditionally executed operations. As I mentioned before, this looks a lot like role-based security. But you can generalize to other cross-cutting concerns, like logging, dependency injection, or performance management. Draw inspirations from clean approaches and patterns for handling those concerns, and apply them to feature flagging.
And while you’re at it, make sure you have a specific policy for retiring feature flags when you no longer need them. Debt piles up in your codebase when no one bothers to clean out the cruft. Make sure you do so, and as time goes on, make sure you automate your checks for outdated feature flags. Maintain rigid discipline about keeping the logic in your codebase to a minimum.
As I mentioned earlier, feature flags are too powerful for you to ignore them. They can help immensely in many ways, including managing other sources of tech debt. And while they can introduce their own flavor of technical debt, they don’t have to. Using a feature flag management system gets you the best of all worlds.