Fear of Breaking Production Code

At every single place I have worked, there has always been this fear of breaking code that already works.  We are never allowed to update code without a "business reason".  This is really frustrating for me.  I like creating common code that allows reuse.  The reusable code often brings down the cost of implementing new requirements, but that is very hard to quantify.  Therefore, I'm stuck with old code that I am forced to "maintain" but I'm not allowed to "update".

Most recently, I was working on a page that had a few legal disclaimers on the bottom.  After the disclaimers was a link to a page that had more verbose disclaimers.  When I asked about the details of the disclaimer page, I was told that it already existed; that I should just use the existing page.  I dove into the code and found that the disclaimer page was NOT implemented in a way that promoted code reuse.  When someone else needed that disclaimer page, they resorted to copy-and-paste programming!  This left me in a bad situation.  My business would not accept the idea that I couldn't just reuse the existing disclaimer page.  In their view, someone else was able to reuse it, therefore I must be lying.  Therefore, the cheap thing to do would be to just copy-and-page all over again.  I don't like doing that.  Alternatively, I could re-implement the disclaimer page in a way that is reusable.  All developers could call a new library that I write that displays the disclaimer page for them.  This makes it cheaper to implement the requirement in the future all while not costing a lot of money: the reusable logic actually isn't that complicated.  You just have to implement it was reusablity in mind the first time around.  I chose to go with this option, but I now have two different implementations of the same page!  I'm not allowed to retrofit the new implementation, since that could "break working code".  There is no guarantee that the next time this requirement is added, that developer will use my reusable version.  In fact, the business will probably tell them not to talk to me since I gave them a hard time in the first place.

This was just the latest example.  I have run into this multiple times.  It doesn't matter that you can improve the code.  Changing the code means risk.  Everyone is afraid of that risk; especially if they don't understand that there is a cost benefit.  To me, there should have been test cases and automated tests that mitigate those risks.  What irritates me the most is the people who tend to be really against software maintenance are also the ones that tell me automated unit tests are a waste of time!

Software should have automated test cases.  Test cases and requirements should be clearly documented (I am still bad at this one).  Code coverage should be reasonably high (I let developers define "reasonable").  There should be a clear, repeatable elevation plan that supports rollback.  If you have all of these things, the risk should be so small, that you should be able to perform software maintenance tasks while minimizing the risk.