Sure, but there are several arguments for doing code reviews/QA/etc that are already convincing. Its interesting.. but I guess I don't see how we can use this new way of looking at code transformations to our benefit.
The thing is even if QA and testing is fine now as the business or domain needs evolve over the years just the fact the context has changed can lead that code to be a liability. I'm kind of tired from work so I hope I can make my point: As an example, let's say you have a billing system that allows anonymous payment that works fine it has thus far been an asset, but new legislation is released that states that all purchases must have legal identity associated. Orwellian thought aside, some or all of that code has transformed into a liability depending on how deeply ingrained anonymous payment is and whether or no you can extend the existing code or you have to rip it out. Your code can be perfectly functional but a change to the domain need rendered it a liability.
All Code implements a process. If the requirements for that process change (due to shifting regulation, for example), the process is a liability until it adapts to those requirements, at which point it can again become an asset.
If a process has no artifacts for implementing it, it can’t be a liability.
That’s why we see so many companies offering regulatory compliance as a service, in the healthcare space for example (AHIP, NIPR). Because if every insurer had to write code that integrated with regulation, they would be writing a lot liability. Using a vendor allows them to offset that liability to a third party, whose whole purpose in existence is to maintain a nice liability:asset ratio.
Perhaps we’ve found a utility for my theory, in contributing to the build vs buy discussion :)