We're way past the tipping point. Software used to be built. Today it is increasingly assembled. This is largely a great thing. We assemble digital experiences quicker than ever before. Software craftsman have been able to move up the value chain.
Software is assembled from off-the-shelf components in the form of OSS and third-party APIs. Unlike similar components we might use to build a physical product, software components evolve at their own rate. We don't control that evolution. Fail to keep up? Our software stops working.
We've accepted that keeping these components up-to-date is technical debt, a term originally for self-imposed debt that we will some day have to pay down. But this kind of debt isn't something we can choose to accept!
Industrialized production requires industrialized maintenance.
If our car breaks, we don't fire up a forge in our backyard and hammer out a new component to repair it. We buy a part designed to repair the defect and we deploy it.
Migration engineering can be automation rather than clerical work.
Starting with platform teams (or developer productivity teams, engineering tools teams, etc.), we should begin thinking of migration engineering as a discipline that requires systematic automation, not endless clerical work, and definitely not the work of shaming other teams into doing clerical work.
We are too far along the industrialization curve for migration engineering to continue to be manual.
We will continue to produce new software at this elevated rate. Migration challenges aren't one-off problems -- it is a new reality of the industrialized software development world that we live in.
- One company we work with has gone from having 40 to 1,200 source code repositories in the last 8 years with zero increase in engineering headcount.
- Another company we work with has over 20,000 applications built on a variation of Spring Boot. Every time a Spring engineer makes a breaking change, that's 20,000 repositories to potentially change. Ouch.
