Branch By Abstraction?

Yes, by abstraction instead of by branching in source control. And no, that doesn't mean sprinkle conditionals into your source code. It means to use an abstraction concept that's idiomatic for the programming language you are using.

Context: Some types of non-functional change take so long to code that someone suggests doing the work on a branch and merging back later. These will be the types of changes that are going to impede the concurrent development of normal functional deliverables. Where the non-functional changes impact many parts of the codebase, there is a risk of repeatedly breaking the build. Where there is a risk of breaking the build, there is a "do it on a branch" suggestion.

Another factor driving that suggestion is when there is a mismatch between the release cadence and the time needed to complete the work. In other words, change can take many weeks or months and there will be releases to production before the completion of the work in question.

The new branch idea would be OK if the resulting merge back could be instantaneous and guaranteed to be a pain-free merge. That is impossible though for any higher throughput development team that is also doing regular refactorings as they go. Note too that executives often express their displeasure with nonfunctional work taking longer than promised by canceling it.

Branch by abstraction is a methodical procedure which has some steps:

1. Introduce an abstraction to methodically chomp away at that time consuming non-functional change
2. Start with a single most depended on and least depending component
3. To not jeopardize anyone else's throughput, work in a place in the codebase that is separate to the existing code
4. Methodically complete the work, temporarily duplicating tens or hundreds of components
5. Go live in a 'dark deployment' mode part complete as many times as needed
6. Scale up your CI infrastructure to guard old and new implementations
7. When ready, switch over in production (a toggle flip to end 'dark deployment' mode)
8. Lastly, delete old implementations and the abstraction itself (essential follow up work)

That last is the characterizing difference between the methodical branch by abstraction procedure and the ordinary and lasting abstractions in your codebase. The removal of the abstraction (and old implementation) is the equivalent to the merge back from the branch that you've now avoided.

Here are the steps of the methodical Branch by Abstraction procedure illustrated using a series of changes to the constructon of the Empire State Building if it were made of software not steel and concrete

It is 1931 in our software alternate universe, and the Empire State Building is pretty much complete, but news has come in that "30 Rock" (a building being planned nearby in New York City) is going to have wheels. Given that, the owners have asked the architects to redesign the Empire State Building to have caterpillar tracks. Not only that, but the switching from a fixed foundation to the tracked design will happen concurrently with the floor-by-floor finishing and tenants moving into the lower floors that are already finished.

Lead craftspeople (still-coding architect equivalents) introduce an abstraction at a critical layer in the building that will be where the static foundation is swapped out, and the caterpillar tracks swapped in. That abstraction is put in place in what feels like the blink of an eye, but in reality took a day or so to prepare in an parallel universe. Before, during and after the placement of the abstraction all workers carried on at full speed and were barely aware that the abstraction was placed in the building (in the ceiling of floor 5), if that was not implicit from 'blink of an eye' as mentioned.

A caterpillar track for the building is assembled in parallel. Methodically so, and tested as it is being made. Testing includes ensuring it fits the abstraction and only involved two workers (developer equivalents).

Everyone working on/in the existing building carry on as normal with the on-traditioanl-foundations design, and are unaware that that caterpillar tracks are bing made and indeed tested ahead of deployment.

In what appears to be the blink of an eye (again) the caterpillar tracks are put in place and the old floors 1-5 are taken out. As before this was prepped in a parallel universe, and flipped over via a toggle with all workers carrying on at full speed. Woe betide any workers still working on floors 1-5 while that happened, but all workers on the ther 97 floors were all safe.

Finally, when everyone is sure that the building isn't going to go back to the on-foundations varient (which would be easy), the abstraction and former floors 1 to 5 are destroyed, and to all intents and purposes it was as if they never existed. To those in the building at the time, as before, this was instantatenous with no bumps/tremors or flickering of lights.

Thanks to Arsalan33 on Fivrr for the "Empire Crawler" artwork.

Thanks also to me for previously writing "Building Software is Nothing Like Building Buildings" blog entry that featured the Empire State Building.