Browser Tab Quest: Feature Toggles
• Mark Eschbach
Join me on my quest to get ride of some of the 60-some-odd tabs open on my phone! This is just a single tab. Perhaps I’ll retain something. Perhaps you will too.
First up! Feature toggles by Hodgson.
It drives me crazy to see these comment based toggles! I know they are useful, but man. The worst part is I forget to clean ‘em up after I’m done. They are great for refactoring legacy code though. I do like the terminology Hodgson uses though, so I’ll probably yoink some of that!
I’m just guessing at this point, however I’m unsure what the difference between a Toggle Configuration and a Toggle Context is. I’m going to move forward with an operational definition the Toggle Configuration is a environmental configuration (either a file or environment variable) while a Toggle Context is something containing business logic.
Grasping for words of a concise defintion, I feel like I really need an in depth study of Canary Builds, and different roll out styles. I really like his idea of using A/B testing; the idea has always sounds great. Unfrountely I’ve never met a system which does this yet. Perhaps at Rhumbix. The idea of a HiPPO is new by name, definitely not expierence; going on the list of future reading adventures.
Probably from my lack of expierence using them, however I disagree with Hodgson on the topic of Toggle Operator. My primary expierence with dynamic toggles (not deploy time) hails from StreamSend, however the question of how much UI to build quickly becomes important. Sure, on a Rails system you can just shell up and toggle it; the Ops people could just use SQL if they didn’t want to Ruby. However it requires people knowing the right access controls and if they are automated or a human system.
There are no arguments I can find against the other two categories, logevity and dynamsism, though. I really love the idea of using _Release Toggle_s to separate feature deployment from code deployment. I wonder if I could use a modified version of this to deal with database migrations within code; although these probably count as oprational toggles. Hodgson has these cross into the
Changes with runtime re-configuration, so perhaps not.
_Expirimental Toggle_s are fiarly straight forward; probably because I haven’t used them enough to really manage them well.
_Ops Toggle_s are an interesting classification. We haven’t really needed them in many of the systems I’ve been responsible for supporting however I know large organziations support _Ops Toggle_s all the way down to making the system read-only. Kind of crazy to think about however I could see them being helpful. The Circuit Breaker will probably be the next article I do write up on…‘cause it’s an open tab right now.
Ah, the Permission Toggle. Definitely the type I’m most familiar with. I’ll agree most of them are long-lived in terms of his scales.
Although I love the Fundamental theorem of software engineering, I’m not entirely sure I fully agree with Hodgson’s assertion; perhaps I haven’t suspended enough belief about the complexity. As it stands now, the extra strategy feels redundent. I suppose you encapsulate the name of the toggle though and give it a formal name though? I guess you also insulate the change which makes sense givne his narative.
In total agreement with Hodgson about a DI container would make the system a cleaner.
I don’t think there are many comments to be made here. Based on the requirements for toggles I think they speak for themselves on what is appropriate. I like his review of the different types. Nothing more annoying than having all the configuration in the single monolithic database with no way to get it out.
Working with feature-toggled systems
Love the idea of exposing the toggles. Totally in-line with some ops-work I did yesterday exposing a lifecycle endpoint; well the idea is in-line but for two totally separate things. Alright, they are nothing alike, I still think both are great ideas.
I like the idea of making toggle descriptions more readable, including embedding metadata. I’m tempted to do that at the current org I work for. The idea of an expiration is a little strange though. I’ll have to chew on it after I finish reading the file.
Hodgson’s examples of validation complexity is great. I’m not entirely sure if I’m on-board with not testing features which are toggled off. Interesting recommendation to pull as much of the toggling out of the core of the application and place it on the process boundary. This might work well for many examples (IE: changing the form), however I’m not sure about it’s applicability to things such as a new ranking algorithms. Perhaps if you build a functional system instead of an object-oriented system this might be a valid approach?
- Toggle Point - A function point which decides the state of a toggle, delegating or executing the work.
- Toggle Router - The function point which makes the decision as to the state of the toggle.
- Toggle Configuration - Toggles configured via environmental, code, or configuration file.
- Toggle Context - Usually user based context of execution for determining the state.
- Toggle Operator - Entity which performs the toggling
- Release Toggle - A toggle which is modified upon deployment laone
- Expirimental Toggle - A toggle which allows for domain defined A/B or other per-user criteria.
- Ops Toggle - A toggle modifying operational attributes of the system, generally technical in nature
- Permission Toggle - A toggle based on some security rules, either business or technical
Overall I enjoy the idea of feature toggles. They definitely can provide combinatorial explosion of testing cases however that is why we automate our testing, right?