On the other hand, I am now looking at a system that has been fast-track maintained for multiple years, to the point that a simple change now takes multiple days of puzzling over mysterious side effects. I can't even begin refactoring it. I don't know where to start. It's a tightly interwoven ball of 'interesting' decisions, patches, changes and obsolete requirements. The fact that all the original developers no longer work in this place is additional bonus. The only plausible solution seems to collect the current business needs and rewrite the damn thing.
On the other hand, it's an opportunity to rewrite the custom system into a product. Clients have shown interest in having their own copy multiple times, but the cost of implementing that horrorshow on their systems has always been a prohibiting issue.
It sounds like most custom IT business solutions. This brings to light something I have been pondering for a while now.
Basically, there are two types cultures related to development teams.
Culture A, treats the software as their business and respect it as much as they do their customers, employees and partners.
In an "A" department developers are empowered to take ownership over the code. This means that they feel obliged to refactor
code and improve comments, documentation, and tests as a part of of whatever change they are delivering.
It is understood that bugs can come from this but that the overall benefit of not ending up with an unmaintainable system
is worth the cost of an accidental bug from time-to-time.
Culture B, treats the software as a necessary evil or at best a commodity. Developers are instructed to perform the least amount
of changes to meet the changing business requirements. These department are almost always in crises mode as the inflexibility of there
bubblegum patchwork has put them into a reactionary relationship with the team who is driving the requirements.
In "B" departments you often see high turnover by the best engineers since they feel something is wrong with the departmental management strategy.
The high turnover in turn leads to less knowledge about the most complex components in the system and even more reluctance from the management
and engineers to risk refactoring something that no one completely understands.
I've noticed the "B" shops are always looking for a new silver bullet, the new servers to be able to run the integration tests in under 48
hours since the code is not unit testable or changing frameworks every two years in hopes it will lead to a more flexible system.
Unfortunately, in my experience, the "B" companies tend to pay the highest salaries.
On the other hand, it's an opportunity to rewrite the custom system into a product. Clients have shown interest in having their own copy multiple times, but the cost of implementing that horrorshow on their systems has always been a prohibiting issue.