Evolutionary Coding Techniques

Deployment Is Not Release

Deployment is a technical action: pushing code to production. Release is a business decision: making a capability available to users. Evolutionary coding techniques are how you deploy continuously while controlling release independently.

Feature flags are the best-known way to make that separation, which is why teams reach for them first. But a runtime if (flag) branch is conditional complexity: every flag combination has to be tested, and the flag has to be deleted later or it becomes permanent debt. Most incomplete work does not need a flag at all. It needs to be structured so the unfinished parts are inert until they are ready.

Use the least intrusive technique that solves the problem. Reach for a flag only when nothing simpler applies.

In This Section

The Hierarchy of Techniques

Work down this list. Each technique carries more long-term maintenance cost than the one above it.

How to Choose

Ask these questions in order. Stop at the first “yes.”

1. Can the change be introduced additively, with nothing pointing to it yet? Use dark code.
2. Does an existing interface already isolate this behavior, or can you extract one first? Use branch by abstraction.
3. Do you need to prove the new logic produces the same answer as the old logic before you trust it? Use parallel run.
4. Are you changing a shared contract, like a database schema or an API, that other code or services depend on? Use expand and contract.
5. Are you replacing a whole subsystem or service, not a single implementation? Use the strangler fig pattern at the routing layer.
6. Is this strictly a business release timing decision, such as a coordinated launch, a kill switch, an entitlement, or an experiment, that none of the above can express? Use a feature flag, and only at the edge of the system.

Reaching question 6 is a legitimate reason to flag. Reaching for a flag at question 1 is not.

Rules If You Do Reach for a Flag

• Flag at the edge, not in domain logic. Put the check in a controller, router, or top-level entry point, never buried inside business logic or a data-access layer.
• Give every flag an expiration date at creation time. No date means the flag is permanent, and permanent release flags are debt.
• Create the removal ticket in the same pull request that adds the flag. Not later.
• Never nest flags. If capability B depends on capability A, extend A’s flag instead of stacking a second flag on top of it.

See Feature Flags for the full flag lifecycle, from creation through removal.

Key Pitfalls

1. “We used a flag because it was the tool we already knew”

Familiarity is not a reason to skip the hierarchy. A flag left in place after launch is technical debt that dark code or branch by abstraction would never have created in the first place.

2. “We picked branch by abstraction, but nothing was calling the old code through an interface yet”

Extract the interface first, as its own zero-behavior-change commit, before starting the swap. Introducing an abstraction and a new implementation in the same change makes the abstraction hard to review on its own merits.

3. “We treated a database migration like a code refactor”

A shared schema or API is a contract other people’s code depends on. Use expand and contract rather than branch by abstraction for anything consumed outside your own codebase.

Next Step

These techniques are what make trunk-based development safe for incomplete work. Once your team can integrate daily without flag sprawl, continue building the test architecture that backs it.

Related Content

• Trunk-Based Development - the practice these techniques make safe
• TBD Migration Guide - worked scenarios using these techniques
• Feature Flags - full lifecycle guidance for when a flag is the right tool
• Architecture Decoupling - the strangler fig pattern for replacing whole subsystems
• Long-Lived Feature Branches - the anti-pattern these techniques replace
• Small Batches - the batch-sizing discipline these techniques support