The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".
Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks?
It really does depend, any code, especially bad code, is very rarely bug free.
So if you ever need to fix a bug the amount of time you will need to spend and revenue you might lose during the time might be worth the refactor beforehand
In my experience, software or product development is never really "done"
Customers, users and business will ask for new features and change of old features, external dependencies and used services will change, hardware will change
Not being able to move fast enough, train new engineers and adjust to changing requirements will have a cost
If I can't trust my codebase not to break on any new change it will be much much harder and more time consuming ie expensive to maintain it
This is not applicable to every piece of code and roi should always be kept in mind but I'm my experience it is almost always the case
Same thing. The time is the investment. There are always projects with better RoI so a rewrite is constantly at the bottom of the pile. "We'll get to it someday."
Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy.
It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.
