What if the discipline of deleting code is the easy half - and letting go of the company you built around defending it is the work?
For thirty years, code was the moat. Years to build, decades to maintain, hard to replicate. The bet made sense and most companies made it - the architecture review, the technical debt fight, the patent strategy, all of it pointed at the layer that took the team the longest to build, because that was the layer competitors couldn’t copy.
Code regenerates in a weekend now. Customer understanding still takes years. The asset that used to compound is the one depreciating fastest, and the domain expertise that used to walk out the door is turning into the durable asset - captured directly from people, and indirectly extracted from the code itself. We protected the code because it was the form of domain expertise we could lay our (virtual) hands on.
So a company can find itself defended and exposed at the same time - the protect-it-at-all-costs attitude still pointed at the codebase, while the knowledge that’s now priceless gets built or lost in decisions no one is treating like they matter. The shift is to protect the knowledge the code was based on.
Jason Goecke makes the same argument inside the software stack in his recent piece: the durable artifact isn’t the code, it’s the spec, and the incumbent’s curse is the rational decision to preserve what should be regenerated - continuing the thread Chad Fowler opened. The discipline he names is cultural comfort with deletion, because the spec is what regenerates the code.
The same shift runs at the company level: comfort with letting go of the identity built around the current solution, because the capacity to reorient is what regenerates fit. The architecture question is whether you’re willing to delete the code. The CEO question is whether you’re willing to let go of being the company that sells what you sell - long enough to discover what your market needs now.