Funny that our software is used to engineer and operate FDA approved production lines. Food & Beverage and Medical are harmless in comparison to continuous Chemical. If a contentious chemical plant fails, you don't just have loss of production, you may need to scrap part of the installation. With some processes the reaction happens in the piping and the material may harden in the pipe requiring the replacement of said piping. Not to mention the operation and control of nuclear reactors.
But since we build the engineering and run-time software for industrial installations, we are decoupled from their narrow and seldom maintenance windows. Nevertheless there is little margin for error. I would rather have a body of software that is properly maintained than a collection of band aid. (Some bits actually are in that state.) To counter that we normally have a ratio of 1-1 developers to testers and in cases of major versions 1-2. Just because I gloss over the budget allocations of new development (80%) vs. maintenance (20%) does not mean we are not committed to quality. Rather the opposite, cleaning up code so a feature fits better in the total architecture is right thing (tm) to do than to try to wedge a the square into a round hole.
But my point stands "we don't have the budget for maintenance" is a lame excuse. Either the maintenance is important and it will be done or it is not and then the developer needs to get his priorities adjusted with the business requirements. Actually "we don't have budget for X" within company that make billions of revenue always a lame excuse. If it is important it will be done, regardless of budget allocation; if not... well then it is not important.