3 ms·

That does not sound much like a “weekly release” though > rather-trivial engineering cost I personally disagree with this. To implement feature flags your eng

That does not sound much like a “weekly release” though > rather-trivial engineering cost I personally disagree with this. To implement feature flags your engineers have to reason about all the places where the feature needs to be on/off, implement those flags, write and maintain test cases for both the on and off case, rollout the code, then go back and refactor everything to remove the flags afterwards. It’s not insurmountable. But it’s not trivial in my experience.

q7xvh97o2pDhNrh 4y ago
> That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a given individual user. From that person's perspective, they are indeed seeing things change only weekly, and the details of how that's done (e.g., feature flags vs giant deployments) are mostly irrelevant to them. > It’s not insurmountable. But it’s not trivial in my experience. You are right. Honestly, I'm so used to having to sell the idea that I just reflexively wrote it that way. Thank you for listing out the different pieces. You're absolutely right there is a lot of extra "essential complexity" that gets added in. Even if the "actual" coding work is "just a few" extra if-clauses and tests (which is how I'd sell it ;), everyone has to hold a lot more in their heads. Personally, though, I would still insist that it's way better than the essential complexity that gets added everywhere by coupling "releases" with "deployments." In my experience, once an org lets product-release-tempo dictate engineering-velocity-tempo, the bureaucrats essentially have a chokehold on all engineering decisions. The organization slowly grinds to a halt; high-value customers start getting picked off by nimble, faster-moving startups; and the circle of life continues. Feature flags are IMHO a key technique for a startup-that's-getting-bigger to hold off this particular mechanism of decline. Non-technical stakeholders at all levels can be easily waved off with a simple remark of, "Well, we'll feature-flag it." And engineers can stay much more empowered, even as the company grows much bigger.

q7xvh97o2pDhNrh 4y ago

> That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a given individual user. From that person's perspective, they are indeed seeing things change only weekly, and the details of how that's done (e.g., feature flags vs giant deployments) are mostly irrelevant to them. > It’s not insurmountable. But it’s not trivial in my experience. You are right. Honestly, I'm so used to having to sell the idea that I just reflexively wrote it that way. Thank you for listing out the different pieces. You're absolutely right there is a lot of extra "essential complexity" that gets added in. Even if the "actual" coding work is "just a few" extra if-clauses and tests (which is how I'd sell it ;), everyone has to hold a lot more in their heads. Personally, though, I would still insist that it's way better than the essential complexity that gets added everywhere by coupling "releases" with "deployments." In my experience, once an org lets product-release-tempo dictate engineering-velocity-tempo, the bureaucrats essentially have a chokehold on all engineering decisions. The organization slowly grinds to a halt; high-value customers start getting picked off by nimble, faster-moving startups; and the circle of life continues. Feature flags are IMHO a key technique for a startup-that's-getting-bigger to hold off this particular mechanism of decline. Non-technical stakeholders at all levels can be easily waved off with a simple remark of, "Well, we'll feature-flag it." And engineers can stay much more empowered, even as the company grows much bigger.