202109251102 Reclaiming software systems
#structureSoftware systems are organic entities. They take on a life of their own over the passage of time under the pressure of external forces. They slowly transition from 202109251124 Golden age software to 202109251125 Post-apocalyptic software.1
How do we get from golden age software to post-apocalyptic then? At some point we find an elegant extension to the golden system. It's looked at as proof of the system's power and flexibility. But in reality, it's the beginning of the end. It causes the system to be harder to reason about, and eventually becomes impossible. It's better to build systems for the problems they solve and keep them running with simplicity.
Each company is allowed to rewrite exactly once, but afterwards you have to learn how to reclaim your software instead.1
One option is to rewrite the system. This is expensive, time consuming, and may actually cause problems by losing years worth of sweat and knowledge that's been put into the system.2 The good news is that rewrites aren't inevitable here, and we can reclaim the system instead.
Reclaiming the system is the project of evolving beliefs into behaviors and properties (202109251100 Verify behaviors and assert properties). We start off by believing that something works like it does. This might be a specific property of "all the DB calls come from ActiveRecord" or something. We turn that belief into a behavior or property that can be tracked and verified or asserted.
Big ball of mud, 202106010000 Rewrites Are (Almost) Never the Answer, this method is almost the same as pinning tests (which I've personally seen the value of and this confirms my intuition) => #thread
-
Larson, W. (2019, July 28). Reclaim unreasonable software. Irrational Exuberance. https://lethain.com/reclaim-unreasonable-software/ ↩ ↩2
-
Spolsky, J. (2000, April 6). Things You Should Never Do, Part 1 Joel on Software. https://joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ↩