[osigurdson]

Trunk based development, while fashionable today does have some theoretical downsides. Imagine a feature toggled code base in the limit - no actual functionality, just partially baked features behind toggles. The end result is a series of branches manifested in the code itself - with no actual "mainline" as nothing has ever been completed. I'm pretty sure that would not be awesome.

Of course, a branched code base in the limit is similarly never merged which obviously is terrible as well. My main point is don't follow trends, instead simply do what what makes sense - that might mean feature toggles, branches or some combination. Stay awake, be creative and avoid dogmatism: sometimes things are better out than in, other times better in than out.

[civilized]

A single code base with half-baked code under feature toggles seems different from "a series of branches manifested in the code itself". Branches would mean there can be different versions of the same half-baked feature that need to be reconciled.

Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?

[osigurdson]

This hypothetical is fairly broad but it is certainly possible to have a branch per feature (i.e. a feature branch).

[civilized]

Yes it's possible for feature branches to look a bit like feature flagged code, but other than that, the administrative and organizational implications seem very different.

The most obvious being, it's a lot easier to see everything when it's in one place.

[osigurdson]

The hypothetical is the code is half baked, never completed and obsolete. In TBD, work is required to remove it. If using a branch, nothing needs to be done.

[civilized]

I guess I would hope that some thought or review takes place prior to merging to the trunk, such that the work merged there is suitable to build on, not just everybody's unfiltered shower thoughts.

That, to me, is the difference between committing on a branch and merging back to trunk/main. A branch is just a way to record and share an idea. Merging back is saying with some confidence "this is something we should build on". Feature flags allow you to disentangle that social signal of "we should build on this" from "this works in production".

I'm not sure (and curious) about other ways of working that can fulfill the same collaborative social signaling function.