It shouldn't surprise me that there are lots of people from the software industry in a Tesla forum
I may have dragged this topic off-track.
Doesn’t really work that way in practice as testing inevitably gets pushed to the back burner with a promise that they’ll be added later and then never done.
Sadly I'd have to agree. Anyone that doesn't do
at least test-first development, and ideally test-driven development, should not be allowed to write production systems consumed by members of the public. If digital infrastructure was physical, there's no way authorities would let it be built the way that large enterprises generally tend to.
You are mixing two concepts: feature flags and agile development
I'm not, although I should have been more clear that I was referring to feature flags to disable unfinished functionality and prevent those code paths from being used in production. I'd expect this to be used to allow WIP to be committed to master/main when practicing continuous delivery. Between process boundaries is a bit different, you can get around that with different minor/patch releases of services being available concurrently, and rely on the routing layer to ensure clients get the behaviour they're expecting.
You cannot hide everything behind feature flags
Having everything behind a conditional feature flag also makes testing near enough impossible as you end up with an impossible number of permutations
You pull out the feature flags once the code has been enabled in production. I'd agree that long-lived feature flags are bad; they should exist as long as is necessary and no longer for exactly the reason you mention.
what incentive is there to fix bugs if it could get you fired?
Reminds me of a gambling company that I worked with, where the testers got a bonus dependent on the number of
passing tests they had. Would you believe that their tests didn't find many bugs?
Also, side effects, even 'impossible' ones, are a thing.. you *never* develop in the mainline release code. Feature flags won't save you from that. You keep feature branches as short and concise as possible but those *always* go through at least testing before a merge.
I absolutely, categorically disagree on this in the strongest possible terms
Continuous delivery requires trunk-based development, and a stop-the-line CI/CD pipeline that means that if something is broken, no-one gets to deploy any new functionality until the blockage is cleared - again inspired by the Toyota Production System. I would agree that code changes must always be
tested before being
deployed, but not that they need to be tested before being merged.
Some continuous
deployment purists would argue that testing before deployment isn't even necessary, and it's better to have very responsive rollback mechanisms and progressive rollouts. The weakness of this approach is that causality becomes hard to track in large, distributed systems, and doesn't protect against emergent phenomena.
Git Flow and feature branch-based workflows work for open source projects contributed to by unknown, untrusted and uncontrollable third parties - this should not be an aspiration for an enterprise working on a product. They delay feedback (discovery of merge conflicts, semantic conflicts) increasing lead-time-to-production and increasing the risk of rework being needed. This is in addition to incentivising isolationist approaches from developers working solo, and a lack of shared vulnerability allowed by developers rebasing the heck out of their feature branch before raising a PR, so that no-one else on the team ever saw all the mis-steps they made on the way to getting the perfect commit.
If you don't trust trunk-based development, that's a smell that your processes, tests and monitoring aren't good enough.
