Onwelo’s Post

Recently I was chatting with someone who had a downtime on production due to, guess what! "a feature flag toggle". Short story below. The feature flag was always in off state. Product team toggled the flag to make the feature live after 4 months. This resulted in an incident and nobody could figure out why/how for more than 30 mins. Lot of teams use feature flags as convenience to the reduce deployment risk. But this doesn't really _reduce_ the risk. The risk just moves from "deploy time" to "runtime". Now, instead of "will this deployment break?" you end up asking "which combination of 15 feature flags will break?". One advice I have is: Don't keep feature flags for months and months. Prune them and reduce the cyclomatic complexity in the codebase. Without regular care, feature flags pile up and the code becomes unmanageable. Feature flags are great for gradual rollouts. They're technical debt when they become permanent configuration. Every flag you add is a code path you need to test and maintain.

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?”

Consistent build processes aren’t just a best practice—they’re a competitive advantage. By embedding automated quality checks into every pipeline, teams can catch issues early, avoid production mishaps, and keep developers focused on building—not firefighting. The result? Faster delivery, better software, and stronger engineering outcomes. Explore more insights in our 2025 State of Engineering Maturity report: https://lnkd.in/eJwgBacY

A feature only matters if it solves a business problem. 📈🧑💼 My approach to problem-solving always starts with the bigger picture: ✔ What’s the business outcome we want? ✔ How can I simplify the process for users? ✔ What’s the fastest way to deliver value without overcomplicating the build? Only then do I move to design, code, and testing. Problem-solving is less about code — and more about connecting technical work to real-world outcomes.

"Technical debt is like entropy. It's not good or bad, it just exists and must be managed." – Anonymous In software development, technical debt isn’t a failure, it’s inevitable. Like entropy in physics, it accumulates as systems evolve. The difference between resilient teams and struggling ones? How they manage it. ✅ Prioritize refactoring ✅ Bake debt discussions into sprint planning ✅ Document trade-offs transparently Technical debt doesn't go away on its own. But when acknowledged and addressed, it becomes a tool, not a threat. #SoftwareDevelopment #TechnicalDebt #EngineeringExcellence #Agile #DevLeadership #CodeQuality

Let’s start with a radical idea: the best way to avoid breaking change problems is… not to have breaking changes. Shocking, right?   In practice, though, we live in the real world where software evolves, and multiple versions of the same interface might coexist during rollouts. If those versions are both backward and forward compatible, life becomes a lot easier: no frantic patching, no unexpected outages, no hair-pulling.   Using the latest version wherever possible reduces the overhead of juggling version numbers or maintaining parallel tracks. But we still need safety nets—because breaking changes have a nasty habit of sneaking past human attention. That’s where automatic governance comes in: think contract tests, CI/CD checks for breaking changes, and similar guardrails.   And here’s an important mindset: the solution doesn’t need to be perfect from day one. Start small—have CI/CD check message-level schemas first. Then gradually extend coverage to interface-level schemas (OpenAPI, AsyncAPI), and complement with contract testing for critical areas. Over time, you get a robust safety net without stifling speed.   At the end of the day, it’s a trade-off between speed and value. Encourage adoption, capture value early, and iteratively strengthen your governance. Breaking changes? Less scary already.

20 minutes from bug report to deployed fix. During this week's All Hands at Stan, Creator Marta Rus joined to share her feedback on Stanley (Your Content Coach). She loved the product but mentioned one issue with transcription. Jason Cameron, one of our engineers, was on the same call. While we continued our discussion, Jason quietly started debugging. No ticket created. No sprint planning. No "we'll look into it next month." Just before we wrapped up, Jason unmuted: "Your issue with transcription is fixed." This is how we build at Stanley: • Customer feedback isn't a ticket – it's a conversation • Engineers aren't in a silo – they're in the room • Fixes don't wait for sprints – they happen now When you truly care about customer experience, speed isn't about rushing. It's about removing every unnecessary step between problem and solution. How fast does your team ship when a customer is waiting? #BuildingInPublic #CustomerFirst #StartupCulture

Testing stories and lessons learned. My friend Jackie still laughs about this story, but it wasn't funny at the time. Jackie was so proud of their "comprehensive" test suite. I mean, this thing had about 2,500+ tests with 97% code coverage. She used to brag about it each time I asked about work. Then, one faithful morning, their entire platform went down for 6 hours, and guess what their amazing test suite caught? Absolutely everything, but the bug that took down their platform. Turns out they had what she now calls "The Great Test Coverage Illusion." Sure, they had 97% code coverage, but they had a very low business scenario coverage. The bug was a memory leak that only happened when you had concurrent user sessions. All their tests were running isolated, single user scenarios. They never for once tested what happens when 1,000+ users are all doing different things at the same time. That was their big wake-up call. They realized coverage metrics only measure code execution, not business risk. They completely flipped their testing mindset from "Did we test every line of code?" to "Did we test every way the business can lose money?" She now calls it their Business Risk Testing revolution. Instead of obsessing over code coverage percentages, they started focusing on revenue impacting failure scenarios. Instead of individual component testing, they shifted to system interaction under realistic load. Instead of feature completeness validation, they prioritized user journey success under pressure. The results were incredible. Before the shift, they had 2,500+ tests, 6 hour outages, and angry customers. After the framework change, they had 847 targeted tests, 99.9% uptime, and happy users. That's about 60% fewer tests but 80% fewer production issues. She and her team learned the hard way that comprehensive testing isn't about testing everything. It's about testing everything that actually matters to keeping the business running. What's your biggest "comprehensive testing" blind spot story? #TestCoverage #ProductionIssues #TestStrategy #BusinessRiskTesting

Consistent build processes aren’t just a best practice—they’re a competitive advantage. By embedding automated quality checks into every pipeline, teams can catch issues early, avoid production mishaps, and keep developers focused on building—not firefighting. The result? Faster delivery, better software, and stronger engineering outcomes. Explore more insights in our 2025 State of Engineering Maturity report: https://lnkd.in/gqZn4cGK

Ever felt like your codebase is slowing you down instead of helping you move faster? That's technical debt knocking at your door. In my latest blog, I break it down: 👉 How to know if your project really needs a refactor. 👉 How to prepare before touching a single line of code. 👉 Why planning matters more than diving straight into changes. 💡 Whether you're leading a team or working solo, these steps will help you refactor smart, not hard. 🔗 Check it out here: https://lnkd.in/eR_qZQV7 Let's turn technical debt into technical leverage! 🚀 #refactoring #code #cleancode #development #engineering