Het artikel betoogt dat het gebruik van gespecialiseerde software voor het beheer van feature flags vaak onnodig complex is. De auteur stelt dat dergelijke tools architecturale risico's, beveiligingslekken en technische schuld introduceren door het creëren van non-deterministisch gedrag in de code.
Als alternatief wordt aangeraden om feature flags simpelweg hard te coderen, bijvoorbeeld via een JSON-bestand dat bij het opstarten van de applicatie wordt ingelezen. Door deze methode te gebruiken, blijven wijzigingen onderworpen aan het reguliere ontwikkelproces van review, testen en deployment. De conclusie is dat men voortijdige optimalisatie moet vermijden en moet kiezen voor eenvoud en betrouwbaarheid boven trendy, complexe tooling.
Het is oké om feature flags hard te coderen
De risico's van beheer-software
Hoewel software voor feature flag-beheer krachtig kan zijn, vormt het ook een bron van complexiteit en risico. De marketing eromheen is zo sterk, dat toegeven dat deze tools onnodig zijn, bijna voelt als een bekentenis van technologische onmacht. We hebben onszelf ervan overtuigd dat we niet zomaar een paar feature flags nodig hebben, maar dat we moeten kunnen schalen naar duizenden.
Bovendien zijn we gaan geloven dat we functies absoluut tijdens runtime moeten kunnen wijzigen—zonder deployment, zonder herstart, zonder cache-flush, zonder databasemigratie, zonder review en zonder test—omdat de business in brand staat en de enige manier om die te blussen is door de kleur van de knop op de homepage te veranderen.
Architecturale en technische bezwaren
Vanuit een architectonisch perspectief zijn dergelijke systemen weinig meer dan opgepoetste if-statements die in een apart proces worden beheerd. Vaak vereisen ze hun eigen infrastructuur, hosting, monitoring en alle verantwoordelijkheden die daarbij horen.
Daarnaast brengen ze de volgende problemen met zich mee:
- Ontwikkelingscyclus: Ze introduceren non-deterministisch gedrag, wat het lastiger maakt om over de code na te denken. Langlopende feature flags leiden tot technische schuld die de codebase doet verstarren. Hoewel dit risico ook bij hardcoded flags bestaat, is het daar veel eenvoudiger te zien en te beheren.
- Beveiliging: Ze vormen een veiligheidsrisico, aangezien het aanvalsoppervlak voor kwetsbaarheden wordt vergroot.
In elk geval moet het toevoegen van extra bewegende delen aan een softwaresysteem altijd kritisch worden bekeken: is het echt nodig en wegen de risico's op tegen de problemen die worden opgelost?
De kracht van hardcoded feature flags
Hardcoded feature flags elimineren veel van de bovengenoemde problemen; ze zijn eenvoudig, betrouwbaar en veilig. Het is de meest saaie manier om het aan te pakken, en dat is precies waarom het de beste manier is.
Implementatie in de praktijk
Een eenvoudige aanpak is als volgt:
- Start met een simpel JSON-bestand.
- Lees dit bestand in bij het opstarten van de applicatie.
- Gebruik de waarden om de zichtbaarheid van functies te beheren.
Blijf strikt in control over de flags en verwijder ze zodra ze niet langer nodig zijn. Als een flag te lang blijft bestaan, maak de betreffende functie dan tot het standaardgedrag en verwijder de flag. Wijzigingen in waarden verlopen via het normale ontwikkelproces: review, test en deployment.
Conclusie
Voor de meeste teams en producten is deze aanpak meer dan voldoende. Wanneer een team daadwerkelijk het punt bereikt waarop functies op grote schaal tijdens runtime moeten worden gewijzigd, zullen ze dat merken (vergelijkbaar met state management in SPA's).
Voortijdige optimalisatie is niet de juiste weg. Het is slecht ontwerp en slechte engineering; het dient enkel voor korte momenten van zelfvoldane arrogantie op tech-conferenties wanneer de sales-spreker vraagt of er iemand is die deze tools gebruikt.
Het is oké om feature flags hard te coderen
De risico's van beheer-software
Hoewel software voor feature flag-beheer krachtig kan zijn, vormt het ook een bron van complexiteit en risico. De marketing eromheen is zo sterk, dat toegeven dat deze tools onnodig zijn, bijna voelt als een bekentenis van technologische onmacht. We hebben onszelf ervan overtuigd dat we niet zomaar een paar feature flags nodig hebben, maar dat we moeten kunnen schalen naar duizenden.
Bovendien zijn we gaan geloven dat we functies absoluut tijdens runtime moeten kunnen wijzigen—zonder deployment, zonder herstart, zonder cache-flush, zonder databasemigratie, zonder review en zonder test—omdat de business in brand staat en de enige manier om die te blussen is door de kleur van de knop op de homepage te veranderen.
Architecturale en technische bezwaren
Vanuit een architectonisch perspectief zijn dergelijke systemen weinig meer dan opgepoetste if-statements die in een apart proces worden beheerd. Vaak vereisen ze hun eigen infrastructuur, hosting, monitoring en alle verantwoordelijkheden die daarbij horen.
Daarnaast brengen ze de volgende problemen met zich mee:
- Ontwikkelingscyclus: Ze introduceren non-deterministisch gedrag, wat het lastiger maakt om over de code na te denken. Langlopende feature flags leiden tot technische schuld die de codebase doet verstarren. Hoewel dit risico ook bij hardcoded flags bestaat, is het daar veel eenvoudiger te zien en te beheren.
- Beveiliging: Ze vormen een veiligheidsrisico, aangezien het aanvalsoppervlak voor kwetsbaarheden wordt vergroot.
In elk geval moet het toevoegen van extra bewegende delen aan een softwaresysteem altijd kritisch worden bekeken: is het echt nodig en wegen de risico's op tegen de problemen die worden opgelost?
De kracht van hardcoded feature flags
Hardcoded feature flags elimineren veel van de bovengenoemde problemen; ze zijn eenvoudig, betrouwbaar en veilig. Het is de meest saaie manier om het aan te pakken, en dat is precies waarom het de beste manier is.
Implementatie in de praktijk
Een eenvoudige aanpak is als volgt:
- Start met een simpel JSON-bestand.
- Lees dit bestand in bij het opstarten van de applicatie.
- Gebruik de waarden om de zichtbaarheid van functies te beheren.
Blijf strikt in control over de flags en verwijder ze zodra ze niet langer nodig zijn. Als een flag te lang blijft bestaan, maak de betreffende functie dan tot het standaardgedrag en verwijder de flag. Wijzigingen in waarden verlopen via het normale ontwikkelproces: review, test en deployment.
Conclusie
Voor de meeste teams en producten is deze aanpak meer dan voldoende. Wanneer een team daadwerkelijk het punt bereikt waarop functies op grote schaal tijdens runtime moeten worden gewijzigd, zullen ze dat merken (vergelijkbaar met state management in SPA's).
Voortijdige optimalisatie is niet de juiste weg. Het is slecht ontwerp en slechte engineering; het dient enkel voor korte momenten van zelfvoldane arrogantie op tech-conferenties wanneer de sales-spreker vraagt of er iemand is die deze tools gebruikt.
Groetjes,