12 ms·

Quick question, have you ever personally experienced this work on a team, or is this just theory? I'm genuinely interested in collecting good examples of it wo

Quick question, have you ever personally experienced this work on a team, or is this just theory? I'm genuinely interested in collecting good examples of it working. The other article about flickr doing this with feature toggles seemed to be a good fit. <Rant> The reason I ask is that earlier this year, I was working with a client who spent upwards of $3 million USD on a content managed website with a huge consultancy that I can neither confirm nor deny is heavily affiliated with the author of the article you may or may not have posted a link to. They were left with a config-driven feature-toggle system that can only be described as a Rube-Goldberg monstrosity. If statements from old feature toggles littering the codebase and different features toggled on or off in environments that no one knew the meaning of. My favourite was when we discovered after days of trawling through the code that a feature toggle was being used to switch a feature off rather than on. There was also a team-wide ban on branching of any kind, including local branching. This belies a misunderstanding of how git works more than anything else. I went ahead and kept as many local branches as I bloody well felt like, because there's no way they'd know the difference. </Rant>

deleted 13y ago
[deleted]
Chris_Newton 13y ago
I sympathise with that concern, and anecdotally I’m still waiting to encounter a feature-toggled project in my own work where the maintenance overheads didn’t quickly become painful out of all proportion to the benefits. It was bad enough in the days of #ifdef driven development in C, where the meaning of your code and even your entire software design could change based on an arbitrary set of macros that didn’t respect scope, didn’t offer any type safety, and might be defined anywhere: a random header file, a makefile setting some command line option, or just some environment variable on one particular developer’s PC that they set three years ago and forgot about. Making a controlled, reproducible build that you actually trust to be what you think it is is very difficult in that kind of environment. It’s even worse with dynamically typed languages, because now you don’t even have compile-time warnings about redundant code or type safety guarantees on the code inside the feature checks to prove it would run sensibly. To me, it feels like the whole strategy plays right into the major downsides of using dynamic types. No doubt some people would disagree with me, and would never dream of writing code without comprehensive test suites that back it up and are known to have 100% coverage with every possible combination of features toggled in or out. (If you really think you are in this position, I know a guy who’d like to offer you an exclusive financial deal guaranteed to make you rich, if you just send a 25K deposit up-front in unmarked, non-sequential notes to his mailbox in Nigeria.) What really bugs me is that this whole feature toggling premise seems to be caused by the tail wagging the dog. Feature toggling is advocated as a way to do continuous integration. CI is advocated as a way to avoid nightmare merges. However, the existence of nightmare merges presupposes that you can have multiple developers simultaneously working on the same part of your code, making sufficiently intricate changes that merging will cause headaches, but for different reasons and without being aware of each other. Otherwise, they could just communicate effectively, and merge intelligently as they go along if that makes sense. How can any development team possibly get into that situation without some spectacular, fundamental failure of project management and technical leadership? That kind of failure is essentially a social problem, so it’s doubtful that any kind of technical solution could solve it reliably, whether a branching model, or a CI-not-branching model, or any other model for that matter.
aidenn0 13y ago
I have seen this sort of thing work really well. You need really good integration tests, and you need to convince developers that yes, they really should check in half-finished work, appropriately disabled. We used cvs, then subversion on that project, so didn't have some of the issues that git had. Occasionally there are still feature branches, though they more often start out more as prototype/exploratory branches, that involve significant architectural changes, and when it's a clear win, it gets merged in. And yes, banning local branches is stupid; uncommitted code on a developers machine happens instead, which is strictly worse than having a local branch with meaningful commits.

deleted 13y ago

[deleted]

Chris_Newton 13y ago

I sympathise with that concern, and anecdotally I’m still waiting to encounter a feature-toggled project in my own work where the maintenance overheads didn’t quickly become painful out of all proportion to the benefits. It was bad enough in the days of #ifdef driven development in C, where the meaning of your code and even your entire software design could change based on an arbitrary set of macros that didn’t respect scope, didn’t offer any type safety, and might be defined anywhere: a random header file, a makefile setting some command line option, or just some environment variable on one particular developer’s PC that they set three years ago and forgot about. Making a controlled, reproducible build that you actually trust to be what you think it is is very difficult in that kind of environment. It’s even worse with dynamically typed languages, because now you don’t even have compile-time warnings about redundant code or type safety guarantees on the code inside the feature checks to prove it would run sensibly. To me, it feels like the whole strategy plays right into the major downsides of using dynamic types. No doubt some people would disagree with me, and would never dream of writing code without comprehensive test suites that back it up and are known to have 100% coverage with every possible combination of features toggled in or out. (If you really think you are in this position, I know a guy who’d like to offer you an exclusive financial deal guaranteed to make you rich, if you just send a 25K deposit up-front in unmarked, non-sequential notes to his mailbox in Nigeria.) What really bugs me is that this whole feature toggling premise seems to be caused by the tail wagging the dog. Feature toggling is advocated as a way to do continuous integration. CI is advocated as a way to avoid nightmare merges. However, the existence of nightmare merges presupposes that you can have multiple developers simultaneously working on the same part of your code, making sufficiently intricate changes that merging will cause headaches, but for different reasons and without being aware of each other. Otherwise, they could just communicate effectively, and merge intelligently as they go along if that makes sense. How can any development team possibly get into that situation without some spectacular, fundamental failure of project management and technical leadership? That kind of failure is essentially a social problem, so it’s doubtful that any kind of technical solution could solve it reliably, whether a branching model, or a CI-not-branching model, or any other model for that matter.

aidenn0 13y ago

I have seen this sort of thing work really well. You need really good integration tests, and you need to convince developers that yes, they really should check in half-finished work, appropriately disabled. We used cvs, then subversion on that project, so didn't have some of the issues that git had. Occasionally there are still feature branches, though they more often start out more as prototype/exploratory branches, that involve significant architectural changes, and when it's a clear win, it gets merged in. And yes, banning local branches is stupid; uncommitted code on a developers machine happens instead, which is strictly worse than having a local branch with meaningful commits.