This is of course good advice. It's strange that anyone who is more than the greenest professional developer wouldn't do this. Experimental feature flags is basic software development.
>Experimental feature flags is basic software development.
No, it is not basic or even recommended. Experimental feature flags should be used sparingly, especially those that take effect at runtime.
The worst codebases I have worked in were littered with runtime feature flags all over the place, which rendered many tests worthless by creating a combinatorial explosion of runtime complexity.
It is the greenest of developers who use experimental flags liberally.
When I think of some people I worked with who wouldn't grok this, other than the usual types who tend to overestimate maintenance costs carte blanche, it's usually because they confuse API with implementation. This seems to be an increasing problem - people increasingly don't seem to appreciate that you can do massive changes underneath and keep a stable API.
For example let's say a component needs a rewrite. They would scrap the function signatures for the old one, even if the problem being solved and expectations from a callee perspective haven't changed and they would apply equally well to the new thing.
And they would pretty much never use an "interface" in languages that have them, or a wrapper, everything is a direct call into their explicit dependency.
Can be extended to things like web services. Every rewrite renames identical parameters for no particular reason.
Yes, it's a very pragmatic way of improving a running system that you shouldn't break. Copy the old code to a new function/module/class. Keep the old code path in place but add a little feature flag or simply comment out the line that calls the old path and replace it with the new code path. Anything that allows you to easily switch between the old and new. Start fixing it. When everything is done, clean up by removing the old code.
This is a lighter weight version of creating a feature branch and attempting to keep that up to date or doing AB testing. That kind of thing typically involves a lot of project bureaucracy which can make a change more controversial. This way, until you are ready to enable the new path, there is no risk and you can keep on committing/merging changes. The only downside is temporary code clutter.
I've been developing like this for the past few years now but at my previous jobs people still used feature branches, so there are definitely other styles out there.
