Your software is maintainable. That is why you are working on it. In fact, the revenue they get from selling and supporting that software probably supports your loaded salary. If I was managing something that works, I would leave it alone. If you had a house with a convoluted plumbing architecture, would you pay a plumber to clean up the architecture even though it works perfectly well right now? Probably not.

As a software developer, I understand why you want a good architecture, object-orientation, et cetera, so you don’t have to sell me, or any software developer.

I would bet that software product is in “milk-the-cow” mode. They are just trying to get as much profit out of it as possible from existing customers before it dies. If that is not true, then what are the architectural scenarios coming down the pipe? More of the same data? New data? Platform or tool deprecation? High performance algorithms? Expanding customer base? New features? New platforms? Mobile? If there are no new business conditions which will drive you to change the architecture, then the architecture will not change? If your architectural is at the critical point where the next change will cause an incredibly expensive fix, then you’ll have to wait for that to happen before they are willing to pay for a change.

The upside of this gig is that they probably can’t fire you, because Delphi skills are relatively hard to find. And there is job security when you are supporting a profitable product.

Read Joel on Software – Things You Should Never Do, Part I, or hope you managers don’t. Mine obviously had not read it, I bet now, if they have, they wish they had earlier…..

I work on a project rewritten in Java from over a million lines of legacy ADA codebase. We now have less than a million lines of new “Java syntax” legacy Ada program, with a whole raft of defects that did not exist before, and a number of new features that sort of work most of the time. Fortunately we also have a Unit testing framework so when a defect get found we can write yet another unit test that fails, fix the defect, watch that unit pass and a dozen others fail……

Essentially only a fool would chuck out working code for the empty promises of a new code base.

One of my experiences that went well

The system was dead and unable to react to market changes, it was customer facing, looked and worked in an outdated way and had so many bug reports, that the estimated time to fixing them was more than rewriting the entire thing. Some lessons

• The time estimation was wrong BUT
• The new system had new/better features
• It was really easy adding features
• When a bug cropped up it was mostly fixed within an hour
• The user experience was enhanced greatly, because designers had a chance to update the design.

Not so good experience

System was very buggy and had a horrible data model and data access layer. It was actually the technology used that was crippling it. There were discussions on using the current data model but they were abandoned. The new design was necessary to make new features possible.

• The problems from the first system shined through. The reasons things were a mess is because the powers that be were not sure what they wanted.
• Massive delays resulting from constant mind changing killed the project.
• The software itself was running quite well, but the general feeling from everyone was not good.

A refactoring success

I’ve had a few systems handed to me that some would justify to be rewritten (some people are very over eager, and sometimes they simply want to do it because the code looks different).

The particular system was a mess. The layers were all mixed up with no distinguishable data access layer, controls on screens were named Button1, Button2… Variables were re-used, pieces of code were copied wholesale across different classes.

Using refactoring tools helped a lot, but essentially it took about 2 months of dedicated work, interspersed with bug fixes and enhancement requests. Essentially the project could keep running despite the massive internal overhaul. If you start small and fix the little things soon you realise that you can be comfortable working with something.

Lessons I’ve learned

Always try to think of every single reason not to rewrite. Think as hard as you can how you can save a dying system. You would be surprised how much less work it is than you think. Rewrites are a massive gamble, and in good company it will work well. Management usually tries to justify a rewrite by adding features to the new version. This could open up a nightmare of constant scope creep, what-if-we-had-stupid-feature-x, analysis paralysis and all the other bad things that come with a new project.

If your company is good at new projects and there is no way to save it then report on what is bad in the system. Show it to the your managers, get a third opinion from another developer, and take it from there.

As always when it comes to business minded people, present your case as a profit/loss analysis. Your analysis should answer these three questions:

• What additional revenue can be generated by your proposed rebuild? (e.g. 64-bit support could be translated to more targeted platforms)
• What revenue loss does your rebuild curb? (e.g. Having to spend less time and resources in maintenance and adding new features)
• Is the cost of your rebuild justified by enough change in the above two items?

This graphic could help, it’s a function of code base quality and business value of the application:

The chart pretends to be a guide on when a re-engineering of legacy software is justified and when it’s not. For example, if the software has high business value and the quality of the code is poor, then a re-engineering is justified.

How do you make a business case for spending a ton of money writing piece of software that does exactly the same thing as the software you have now, plus, the additional risk that it will not do exactly the same thing?

Good Luck.

Does anyone know of any blog posts or the like where this is talked about?

Yes, here are two articles that you should review and forward to your management:

1. A Mess is not a Technical Debt
2. Technical Debt Quadrant

And here are two points about legacy software to be mindful of:

Legacy software that is difficult to modify will:

1. Limit a company’s options for the future (assuming that the company isn’t looking to just milk the cash-cow).
2. Frustrate current developers and impact a company’s ability to attract and retain new talent.

There is no reason you cannot address the problems that exist in your current project. One does not need to throw the baby out with the bath water. There are lots of ways you can address the problems that exist. If you have a high level of defects then unit testing and validation and verification testing is one of those solutions.

The software lacks any meaningful architecture – there’s no object
orientation whatsoever, horrible amounts of cyclical dependencies and
an over-reliance on global variables to name just a few things.
Another huge thing for me is Delphi 7 does NOT support 64-bit.

Delphi supports nearly every modern programming concept that Java and C# support. This means you could easily solve your cyclical dependencies and global variable problem. You could even solve your object orientation if you wanted. All you would need to do is address a single problem at a time.

The problem here for me is that my management team don’t care about
technical things, they want to know why they should care. Obviously
that’s expected, so what I’m asking here is for some guidance, or
tales, or pitfalls about this kind of thing.

You as their employee believe the software is unmaintainable. You need to make a case for the reasons, you need to come up with a solution to the reasons the project is unmaintainable. If you cannot do this then its very likely the project IS ACTUALLY MAINTAINABLE because it has been maintained for over 20 years.