I have been doing a bunch of workshops for my day job that involve practical hands on experience in various dev ops systems and modern software tools. Some of these may seem remedial to more experienced developers but a big part of the endeavor is to baseline an organization.

One thing I did not expect was the emphasis on strategy or methodology. About 30% of my time if not more is spent on organization and metrics, and how these tools tie in these strategic (or perhaps tactical components).

I could consider something like CI/CD like logistics – how something is delivered to someone else (mostly an end user, but also an internal customer). And remember that Napoleon was able to be so successful because of his superior logistics. But these logistics tie back into an essential strategy. Strategy is the over all way that we achieve some sort of goal. Tactics is small patterns that together execute the strategy, and the logistics is the pipeline that enables the creation of thee small patterns (ie tactics).

I was reviewing an article for an upcoming workshop about how to remove legacy code from a system. Our goal is an easy to maintain system to minimize MTTR (mean time to repair), the strategy is to remove technical debit, how do we do this?

The tactic is the strangle method.
1) Create new code that is a proxy or pass through to the old code.

In this case you can create a new interface without rewriting business logic, and connect new services to the new interface.

2) Begin removing the proxies with real new code that works.

I would suggest doing this as you get feature requests that touch these parts of the code. A second option is just to create each function replacement as an item in your backlog. However, this has the side effect of being overwhelming.

3) Slowly remove the old code base.

This is hard, since there are always unexpected instances when some service, or customer, is hitting a piece of code that does not pass through the new interface. However, if you keep this part distinct from step 2, replacing the proxy in the interface, then you can even instrument the legacy code base to see if and when it is hit, and minimize errors that might arise.

This is one of the many instances where my job is less about technology and more about strategy or tactics. It has become increasingly easy to write software and much of software development is really systems integration these days. The issue is NOT how to write this code, but what strategy to use to build a robust system, resilient system, or as I like to say via NNT, antifragile system.