どの様な話？
逆に、
- 現行システムは「曲げられない」
- どんなに理解し易くなっても！
だと思います。
- 保守フェーズ（「曲げられない」）で、曲げ（≡分かり易さ）が通じない
のはそのせいだと思います。
そして、曲げられない場合に何をやるかというと、
- 因果推論
- 具体的には調査分析
だと思います。すなわち、
- 因果推論こそが、プログラミング手法の第一原理計算
なのでは無いでしょうか？ 第一原理計算は一般に、
- 難しい
のが通例で、一般に調査分析が煩瑣なのもこの主張の傍証となるのでは無いでしょうか？
曲げられる（完全新規開発、既存要件無しの）場合
曲げられる場合には、（針の穴を通す様な細心の配慮の元）SOLID原則を満たす様に作ることも可能でしょう。
しかし曲げられない場合には、まず無理だと思います。
なぜならば、
- （非常に多数から引用され、「曲げられない」原因となっている）因果の元の方が、
- SOLID原則を満たす様になっていなかった
- そこから直すとなると、完全新規開発、既存要件無しとなってしまう
からだと思います。SOLID原則適用の困難さも、第一原理に立ち返って見れば明白なのでは無いでしょうか？
技術的負債の返済の技法
技術的負債の返済の技法も、
- 粗々でかなりの了解は取れている（と私は思う）
けれども、その第一原理計算はやはり、因果推論なのでは無いでしょうか？
第一原理が有ればこそ、粗々にせよかなりの了解が取れると言う物では無いでしょうか？
結論
第一原理計算は難しいので、それを持ち出さないといけない場合、
これからも「第一原理計算？」の突破の困難さにより、プログラミングが嫌いになる人が存在し続けることを、理論的に証明出来る日が来るかも知れません。
