"If you lose the people, you lose the program."<p>I had a protracted, bitter struggle with this at one job. We had a business process, really in the top two of business processes, that was neglected as it was critical. When I was new to that role, I said, "We should rewrite this. This is scattered across multiple servers, the code has almost no comments (in the places where we still <i>had</i> source code), and more importantly, people were leaving."<p>One of the original programmers had died. People responsible for the <i>why</i> of certain decisions were retiring or leaving. And so on and so forth. I used to joke that our process was documented in C, except for the places it was bash, or borrowed Powershell, or ... Like an evolved process, instead of problems being solved, later systems were added to correct issues, only epicycles, even as the bus factor continued to decrement every so often.<p>I still have a low level of sour antipathy when I think of it, that my efforts to "do the right thing" came to nothing.<p>It's a shame. When I had a freer hand to work as I liked, systems I built could detect, in a limited fashion, when the world had changed, that is, if the theory of the world was wrong. If the vendor changed some critical portion of the database, the program would identify the new column or the missing table, then loudly expire after issuing its complaint.<p>This understanding of the slice of the world a program must interact with is so critical and worse yet, fragile, subject to both breakage and decay.