I am consulting as an architect for web development teams. Bridging the gap between product requirements and concrete implementation details.
If your team is having problems completing work on schedule, or you’re not satisfied with development velocity, and feel the need to hire more programmers to help finish the work on time, please reconsider.
It’s highly likely that what you need is not another programmer. Instead, what you need is someone to fill the gap between product requirements and specific implementation details.
If you could give your team a technical document describing how to implement a feature, it will help them do the work in a shorter amount of time to a higher quality standard.
This is what I hope I can deliver for you and your team.
If success is posting stupid click bait questions on twitter, then yes, I refuse to do that.
I’m not a clown or an entertainer. I share my journey and provide value to people. The people who are drawn to click bait content, are not the people I want to interact with.
If we are talking about syndromes, then I think you might have a Stockholm syndrome.
On a more serious note, marketing is an umbrella term. There is clever marketing out there. It’s, however, rare. Most of the marketing is trash in a form of click baiting and being a morale-less clown. And the saddest part, is that it works. That’s why algorithms reward it.
I feel with you, but don't delude yourself in to avoiding any kind of marketing. Marketing is an evil necessity, especially if you are starting from scratch by yourself. That's just the nature of our reality. To scoff and say you're content is an ego-fuelled move, one that pushes the problem off for later.
Don't do that to yourself. Learn to market ethically at least, or else it's a real waste of time as your next startup fails because you avoided marketing.
> It seems to have only caught on because a lot of people felt adrift when it comes to Git and this was written far too authoritatively for what it is.
My hypothesis is the design of the page and the images played a big role in convincing people this is "legit".
Because feature flags often intersect with segmentation and AB testing.
So it's not just a byte in memory, but often also correlating the status of said byte with a users identity and then tracking and summarising user behaviour based on that relationship.
It's become fairly standardised and requires engineer time to setup and maintain the services behind all that, so it's valid to go third party for less than the cost of said engineer time, if all you want is standard.
Edit:it's also hard to always predict when a standard flags going to become part of a test, so just integrating for every flag and making that a standard process for your teams becomes the simplest approach.
I am not a fan nor a user of backend feature flags, so don't ding me for relaying this: they tout features such as central management of these settings, bringing them in the hands of the product team rather than being tugged away in code, allowing for canary deployments where you fade in a feature based on performance metrics, a/b testing, and so on. In their own interest, these folks take an as broad as possible view on what is a feature flag, often including things that you'd otherwise call system configuration or entitlements or permission toggles. It's not a new trend, LaunchDarkly is probably the best known commercial party here, and they've been around for about ten years, and I don't think they were first.
I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.
Aren't there common patterns of good "just code" and bad "just code"? I've been told for a long time that global variables are a bad pattern. Maybe feature flags are a bad pattern too.
One concern about feature flags is testing, and the added permutations of testing needed to include all the feature flags in testing. You tested with flag A on and off, you tested with flag B on and off, but did you ever test with them both on and both off? Without feature flags, a big change that could have been represented by a feature flag would hopefully have to make its way past some quality gates. With feature flags, the exact permutation that you're going to cause later today by flipping on some feature flags may well not have been tested. Not that forgetting to test is something you can't protect yourself against with tools and processes, but testing all the permutations may be expensive.
You may not have to test all the permutations, if you can predict which permutations are relevant for your flipping feature flags later today. But a lot of organizations have poor discipline in cleaning up old feature flags, so it may not be so predictable. Maybe that's not a feature flag problem but an organizational problem, but the feature flags are gonna get blamed at some point, nonetheless.
