The Dangers of Feature Flags: A Cautionary Tale

Feature flags aren’t just toggles to hide unfinished work. They’re a deployment strategy. Used well, they let teams ship faster, test safely in production, and iterate without holding up releases. But that only works if flags are part of the system, not just scattered if statements duct taped into the codebase. Good implementation means structure: naming conventions, lifecycle management, flag ownership, and automated cleanup. Otherwise, your “flexibility” turns into technical debt. Done right, feature flags help teams isolate risk, experiment in real time, and roll out gradually with control over when and to whom. But the flags don’t manage themselves. Without process, they’ll pile up, collide, and break things in ways nobody can trace. So ask yourself: are you using feature flags to control deployment or just to hide the mess?

If this applies to you, help me understand... Why would you NOT want: ‣ A lead time to change: 15-30 mins. ‣ Less than 5% of the team's capacity to fix all new bugs. ‣ Deploying on demand, multiple times per hour. When you currently have: ‣ A lead time to change of 1-2 weeks? ‣ 20-30% of team capacity consumed fixing a subset of a still growing bug list? ‣ Weekly or fortnightly release trains? I don't mean, why can't you do it _yet_ I mean, why would you not want to? (Whether as an individual or as a company) Asking for a friend 😉

Subject: Software development/delivery Antony Marcano's post (see https://lnkd.in/gnHDYEP4) started me thinking about some of the situations I've seen along the same lines. The question, "Why would you not want to?" is pretty puzzling to those of us who've experienced how much easier life can be if we line up the dominoes before we start knocking them over. It occurs to me the answer to the question may not be that people actually prefer doing things the hard way. Their work environment may be a factor. On a recent training engagement, during a preliminary call with client management to clarify the scope and goals of the course, I found myself having to guess at what they were asking for because the manager spoke in cryptic, roundabout jargon that didn't seem to mean anything concrete. Listening between the lines, I came up with an agenda that seemed about right, but going into the gig I was prepared to pivot. A lot. And I did. It was hard to get a handle on what the participants were looking for from the training. Walking through their process, a number of opportunities for improvement became evident. Yet, they insisted everything was fine just as it was. I tried to tease information from them by asking what problem we were trying to solve, so I could adjust the content for them. They kept saying they had no problems and everything was fine. At one point it dawned on me that they were terrified of the word "problem." That was when I realized their work environment was toxic. I asked them how they would like to use the training time, and they guided the rest of the course accordingly. They said they got some value from the training in the end. On another engagement, this time a technical coaching gig, management made it clear that transparency and psychological safety were key and anyone should feel comfortable raising issues and making suggestions for improvement. They abruptly let me go (in the middle of the night with no warning) after I shared information about the improvement goals with the teams I was coaching, following a working session with management. Management had not indicated the information was to be withheld from the teams. It was routine stuff about metrics and targets for improvement. I've seen a handful of places that were much worse than those examples, but not many. Maybe 3 or 4 really bad ones over a 48 year career. The basis of their problems isn't technology or process or tech practices or any of that. The problems arise because an inhumane work environment compels people to worry more about defending themselves than about getting useful things done. It's particularly bad in organizations that do annual reduction-in-force exercises in which a fixed percentage of staff must be laid off, no matter what. 

Why do we use feature flags? Because they let us test in production.. → But isn’t that what staging environments are for? Because they let us delay the release of a feature.. → But isn’t that just about release planning? Because they let us turn a feature off if we change our mind.. → But if the feature is broken, shouldn’t rollback or hot-fixing be the standard? Because they let us run live experiments and A/B tests.. → But shouldn’t experimentation frameworks handle that, not random if-else blocks in production code? They let us hide unfinished work.. → But isn’t merging incomplete code the very definition of tech debt? And after the main use of the flag is over and everything turned to be fine, who will remove the old logic and the feature flag? is it a new task? or is it the remaining part of your "Done" task? And what about testing? Feature flags make tests worse. Every flag doubles the number of code paths. With multiple flags, the combinations explode — and nobody realistically tests all of them. So why do we really use them? They feel like control. They give us the illusion of safety. But often, they replace existing practices (staging, release planning, rollback) with something heavier that lingers in the codebase long after the actual feature is done. The result? Feature flags are often just another layer of technical debt, hiding under the name of “flexibility”. Maybe the real question isn’t “Why do we use feature flags?” but rather “When should we stop using them?”

Defects happen. But it’s the way you track and manage them that separates chaotic teams from high-performing ones. Whether you're refining your bug reporting workflow or looking for tools to help you scale, we’ve pulled together a guide that covers: ✅ The fundamentals of effective defect tracking 🧰 Key tools to streamline the process 📌 Best practices to keep quality at the center of your dev cycle Get the full breakdown here: https://lnkd.in/gpQ-t939

Once upon a time, there was a project whose documented bug list was so long that it would never be addressed. This project follows a 'Roadmap' set in stone three years earlier. Each production release, which date is irrevocable, mobilizes the entire company. No production is possible after the launch, until full completion. Every stakeholder crosses their fingers that the finalization will be completed before midnight, because at 12:30 AM, critical processes begin.  Fortunately, the technical director knows how to circumvent each problem like no one else. He is also a keen sleuth and will uncover, with formidable efficiency, every mistake made during the previous 'Sprint.' The culprit will have a hard time justifying how he managed to deceive an entire team of renowned testers. Yet, with particular attention, each new implementation was checked! Thus, the failures, almost systematic, find justification with management and clients. Therefore, all productivity indicators are positive. This tale is a trial for the development team. The most frustrating part: this situation could be avoided with minimal effort, using simple methods. It is true, however, that taking time to build relevant automated tests can delay the "Roadmap." Initially, this is indeed the case. Once the benefits begin to outweigh the losses caused by insufficient testing, then the "Roadmap" can even accelerate. In my opinion, a cessation of production to install a component should be prohibited. Each transaction must carry all the necessary information for the transition between two states, and be repeatable ('Stateless'). This production is a set of systems functioning together. Each should be independently testable, and also each relationship. Thus, the smaller these systems are, the shorter the interruption time for the final customer will be. Ideally, it becomes imperceptible. You are having a hard time achieving this? May I help you?

One good question can change a sprint. A client once asked their team in planning: “What’s the riskiest assumption we’re making this sprint?” That one question uncovered a missing error path in a critical feature, something no test case had touched. They fixed it before the bug ever existed. No drama. No rework. Just better outcomes. In QED, we treat good questions like test tools, because sometimes, they’re the fastest way to find what matters.

My biggest frustration, at any company, is having to continue adding to the "big ball of mud" of a solution that already exists rather than work on turning that solution into something that actually serves the business' needs while reducing the amount of headache us developers have to put up with. Those concepts are not mutually exclusive! Good solution and software architecture can serve the business and provide developers with the ability to add, modify or remove features without fuss. But it seems that we are only ever interested in "quick wins" or ignoring problems until the last second only to slap a quick fix on it. This cycle just leads to rewrite after rewrite and eventually the rewrite does not do what it needed to do in the first place because it is so far removed from the problem it was originally solving.

🚀 𝗧𝘂𝗿𝗻𝗶𝗻𝗴 𝗥𝗼𝗮𝗱𝗯𝗹𝗼𝗰𝗸𝘀 𝗶𝗻𝘁𝗼 𝗢𝗽𝗽𝗼𝗿𝘁𝘂𝗻𝗶𝘁𝗶𝗲𝘀 During a critical delivery, we encountered a tough challenge: building a seamless file transfer mechanism between environments, while racing against tight deadlines. 🔹 First thought: “Let’s just use S3 as a middle layer”. Upload → Download → Done. But it added latency and unnecessary steps. 🔹 Next thought: “SSHFS should solve this”. It worked, but mounting reliability and session persistence quickly became bottlenecks. ⏱️ With the clock ticking, I shifted gears. Instead of forcing existing tools to fit, We designed a custom FileMover script that:  • Directly watches SFTP endpoints,  • Handles reconnections gracefully,  • Simplifies the entire pipeline while keeping performance high. 👉 The takeaway?  When deadlines press hard, it’s easy to feel “blocked.” The trick is stepping back, reassessing assumptions, and exploring alternatives systematically. 𝗦𝗼𝗺𝗲𝘁𝗶𝗺𝗲𝘀, 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗶𝘀𝗻’𝘁 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗼𝗯𝘃𝗶𝗼𝘂𝘀, 𝗶𝘁’𝘀 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗵𝗮𝘁 𝗳𝗶𝘁𝘀 𝘆𝗼𝘂𝗿 𝗰𝗼𝗻𝘁𝗲𝘅𝘁. 💡 This experience reminded me that being an engineer isn’t just about knowing tools, it’s about the thinking process:  • Evaluate trade-offs fast,  • Fail quickly,  • Pivot smartly,  • Build only what adds value. What’s the most unconventional workaround you’ve built under deadline pressure?

Your branching strategy can make or break your release process. I see many teams using main/master as their release branch. But here’s the problem: If every change lands directly on main, it quickly becomes unstable. You lose clarity on what’s in dev, stage, or prod. Rollbacks and environment testing get messy. In my latest project, I took a different approach: 🔹 Main remains the source of truth only, no direct releases. 🔹 Feature branches → merge into main with pull requests (ensuring peer review + safer merges). 🔹 From main, we branch into dev → stage → prod — each environment isolated, but connected. 🔹 Deployments are triggered by pull requests to these environment branches. Why does this matter? ✅ Pull requests = visibility, accountability, and safer merges. ✅ Each environment can be deployed independently. ✅ Easier debugging: if stage fails, prod is untouched. ✅ Teams gain confidence in promoting code forward instead of fearing regressions. This strategy enabled multi-environment deployments, clear audit trails, and safer rollouts. And it scales whether you’re shipping a small app or running large infra. I’ve documented the full setup, including CI/CD, semantic versioning, smoke tests, and rollbacks, in this blog: Full Blog on Medium: https://lnkd.in/dn84dGbh GitHub Repo: https://lnkd.in/dXfswYgK Curious: what’s your branching strategy for managing multiple environments?