area of the system you want to change 3 – Make a new implementaIon of the abstracIon 2 – Update all code to rely on the abstracIon 4 – Remove the old implementaIon 5 – Remove the abstracIon if it’s inelegant
No need to roll back a release, just disable problemaIc feature • A/B tesIng • Private betas e.g. turn on a feature for 5% of users • Dark launches • ConInuous deployment/delivery
explosion if toggles aren’t acIvely decommissioned • Don’t overload toggles e.g. enItlements (totally different life spans) • Just because a feature is dormant doesn’t mean quality is not as important • Avoid coupling features e.g. feature b can only be enabled if feature a is enabled
• Long lived branches in VCS are bad • Working in isolaIon for prolonged periods of Ime is bad • There’s always another way, it just might require some careful thought and design
• hap://www.se-‐radio.net/2008/09/episode-‐109-‐ebays-‐architecture-‐principles-‐with-‐ randy-‐shoup/ • hap://velocityconference.blip.tv/file/2284377 (Flickr, 10+ releases per day) • hap://www.infoq.com/presentaIons/Feature-‐Bits • ImplemenIng Lean So4ware Development: From Concept To Cash, Mary Poppendieck, Tom Poppendieck