Old codebases are really more about exploiting the sunk cost fallacy, nepotism and cultivating a fear and uncertainty of new technology. That is to say, old co

Old codebases are really more about exploiting the sunk cost fallacy, nepotism and cultivating a fear and uncertainty of new technology. That is to say, old codebases are mostly about organizational politics and social dynamics, rather than anything inherently stable or high-quality about the codebase itself. So basically, if you want your codebase to still be in production 50 years from now, here's what you do: build something important and mission critical. It should be something that could cost millions if it ever fails. Make the design so bespoke and specialized that only you and people trained by you actually know how it works and how to fix it. Fraternize with the management and use nepotism to grease the wheels and convince them to overlook the inefficiencies inherent in your project. This works well in government projects where you can offer kickbacks in the form of campaign donations. Once you are providing a necessity, and there is a real financial risk associated with your system failing, you're set for life. Expect your contract to be renewed next year, and every year after that, forever and ever and ever and ever.