- quick overview of the day
- joint session done on working on big features with toggles
- Socrates day: mid September each year
- SoCraTesDay_CH
- Socrates 3 days: February/March retreat in Ftan Engadin
- Breaking the monolith apart
- Mikado Method
- What you see is not what is there
- Micro frontends
- Pimp up your retro
- Big Features & Feature Flags
- Code Readability
- What is a big feature?
- What are common problems?
- Strategies discussed and shared
- depends on release cycle
- example: 1 week release cycle, big feature takes > 1 week
- User Story (1) -> (N) Functionality tasks
- Functionality task: atomic step a developer can build
- often rebase / fixing of merge conflicts
- overdue, hard to estimate
- lack of feedback or late feedback
- changing / growing requirements
- usually require extensive refactoring
- trunk based development vs epic branches
- feature flags
- pair programming
- daily feedback (demo to customer)
- different types of feature toggles
- long-lived toggles vs transient toggles
- decouples "training support people" vs release
- they add complexity: add them as late as possible
- Goal: as few feature toggles as possible
- Development features (can be hardcoded constants)
- Experimental features
- AB Testing
- User level toggles: gradul release (0 -> 100%)
- one place (prefer static over dynamic configuration)
- UI with toggle buttons
- default values (should work online/offline)
- not inside a method, but delegate between two methods
- duplicate behaviour (less risk of braking things)
Example:
- add feature
- duplicate -> new feature
- once new feature used
- delete old feature
- requires good monitoring
- keep track of them: which versions are running?
- when to delete them?
- deprecation annotations (ex. database fields)