Hiljuti oli kokkupuude dünaamiliste funktsionaalsuse lippude seadistamise teenusega - LaunchDarkly. Kuna projektis oli vaja tutvustada seda teenust uutele meeskonnaliikmetele, siis oli koostatud väike videotutvustus, mis eksponeeris teenuse pakutavaid võimalusi. Kuulates ettekannet hakkas aga häirima tõsiasi, et seal keskenduti ainult positiivsele. See aga jättis väga kallutatud mulje selliste teenuste kasutamisest, maalides sellest hõbekuuli sarnase lahenduse. Suutsin välja mõelda vähemalt paar suurt puudujääki, mida tasub kindlasti kaaluda, enne kui selline teenus suuremas mahus kasutusele võtta. Järgnev puuduste nimekiri ei ole seotud kuidagi konkreetselt LaunchDarkly teenusega, vaid pigem üldistab probleeme, mis on kõikidel funktsionaalsuse lippe pakkuvatel lahendustel.
Lippude uputus
Kuna LaunchDarkly sarnase teenusega on võimalik seadistavaid lippe väga kergesti lisada, siis on lihtne tekkima ka olukord, kus ühel hetkel on neid lihtsalt liiga palju. Nagu ka tavalise koodi refaktoreerimisega, on väga lihtne unustada nende hilisem eemaldamine ja koodi puhastamine. Lippude olemasolu halvendab kindlasti ka koodi loetavust, kuna iga sellise lipu tegelik väärtus on teadmata ja võib ajas alati muutud. Seega peab sellise teenuse kasutamisel kindlasti olema paigas ka protsess, et kuidas oma kasutusaja ära elanud lipud koodist eemaldatakse.
Testimise keerukus
Iga uus funktsionaalsuse lipp luba seadistada, et kuidas äriloogika mingisuguses konkreetses olukorras käitub. See omakorda tähendab, et võimalikkude toodangukeskkonna konfiguratsioonide arv hakkab kasvama eksponentsiaalselt. Isegi kui on soov testida kõiki lippude taha peidetud funktsionaalsusi, siis peab arvestama, et selleks vajaminevate testide arvu on väga keeruline kontrolli all hoida. Kui aktiivselt ei eemaldata aegunud lippe, siis ühel hetkel võib olla peaaegu võimatu kõiki võimalikke kombinatsioone testida. Seega on lihtne lõpetada olukorras, kus toodangukeskkond kasutab sellist seadistust, mida testkeskkond ei kasuta ja mida seega ka ei testita.
Rakenduse seadistused on jagatud
Traditsiooniliselt on rakenduse äriprotsessid defineeritud kas puhtalt äriloogikas või siis kasutavad rakendused konfiguratsioonifaile või andmebaasitabeleid. Dünaamilisi funktsionaalsuse lippe pakuvad teenused aga nihutavad seadistused täiesti eraldiseisvasse keskkonda. Sellisel lähenemisel on küll pluss, et seadistuste haldamisega saavad nüüd teoreetiliselt tegeleda ka näiteks tootejuhid. Kuid miinusena ongi asjaolu, et lippude väärtusi saavad muuta laiem ring isikuid. Mis omakorda tähendab, et kui lippude haldamise protsess ei ole täpselt paika pandud, võib see tekitada korraliku segaduse. Kui puudub ülevaade, et kes ja miks mingite lippude väärtusi muutis, on tulemuseks väga prognoosimatu toodangukeskkonna käitumine.