I work for a great little software company which makes good revenue from our main software package. The problem for me is that it's almost unmaintainable. It's written in Delphi 7 (has upgraded versions over time) and has been worked on by a lot of developers over the past 20 or so years.

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.

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.

There's a few things I would love to include, namely for me, the length of time taken to debug/write a feature in "legacy" code, versus coherent, well structured OO code. Does anyone know of any blog posts or the like where this is talked about? For us in the company this is a huge reason. Despite being decent developers we feel like writing a new feature is just piling more rubbish on top. On top of that, even for me who has a decent level of understanding of the code, changing things is infuriating - a small change can have a ridiculous domino effect.

Anyone have any experiences they'd like to share?

  • 1
    fyi, the latest version of Delphi does support 64bit. – GrandmasterB Oct 4 '12 at 20:58
  • 7
    Never set out with a preconceived conclusion when you do a business case. If you do, you'll skew the numbers and it will be transparent. – pdr Oct 4 '12 at 21:04
  • 8
    Don't do a massive rewrite. Add unit tests, and then refactor gradually. You might like to read the book Working effectively with legacy code by Michael Feathers – MarkJ Oct 5 '12 at 7:05
  • 2
    Why do you think that structured code should be OO? – mouviciel Oct 5 '12 at 7:59
  • 3
    Welcome to the real world! I have seen the code base of several very successful big name software products, and, most of them are exactly as you described, out of date technology, no clear architecture , meaningless variable names etc.. The problem is it takes a very long time to grow a succesfull software product. After a few years your architecture is unfashionable, dozens of people have been in there hacking the code in a dozen different styles, features were added quickly to make a big sale but the documentation was never done etc. etc. Working code always beats pretty code – James Anderson Oct 6 '12 at 2:55

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.

  • 6
    You just have to hope that "convoluted plumbing architecture" doesn't cause you to end up with a basement flooded with excrement one day. Identifying that critical point, where the virtual basement is going to really start stinking, is going to be one of the keys to selling the idea. – jfrankcarr Oct 4 '12 at 21:11
  • 2
    Are you making assumptions there about 64-bit MS Office, at least in the short to medium term? A 64-bit application should be able to automate 32-bit Office, 64-bit Office is very rare 'in the field' and even Microsoft themselves don't recommend it's use unless there is a requirement for vast Excel sheets. – Alan B Oct 5 '12 at 10:39
  • 1
    What you say about 64-bit Excel is true today. I think what the author is worried about is what happens in 2-3 years when the majority of new office computers are running a 64-bit operating system with a 64-bit version of Office. Office 2011 and Office 2013 are both sold as a single version ( x86 and x64 ) and Microsoft also sells Windows 7 and Windows 8 as one package ( x64 and x86 ) which means going forward 64-bit is a MAJOR concern if you communicate with Excel, Access, or any software that currently uses a 32-bit process. – Ramhound Oct 5 '12 at 12:56
  • 1
    You cannot compare plumbing with software! Software is just way more complex, and there are cheap things you can do to fix it, as opposed to plumbing. milk-the-cow is not a good business model. MS missed the smartphone revolution, because presumably their OS was not mobile ready. If your business is software you should do everything to modernise it all the time. After all customers are paying you in good faith to improve your software. They are the cows, so as a customer I would be very upset to buy a product from a company milking me. – Tjaart Oct 22 '12 at 12:58
  • 1
    @Tjaart - Milk the cow is sometimes a great business model and sometimes a terrible business model (for the reasons you stated). But it doesn't matter what you think of the model. Many businesses will put their software into milk-the-cow mode to improve their bottom line in the short run. Also, if you were the buyer of software in milk-the-cow mode, you might be very happy if the cheapest alternative from another vendor was much more expensive in the short/medium run. And that is often reality... – Jay Godse Oct 22 '12 at 18:27

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.

  • 1
    Rewriting from scratch is a last ditch effort to fix things, but usually the policies/people/culture that made the mistakes in the first system now just proceed to make the same ones with a new system. Its a sad sad cycle. – Tjaart Oct 5 '12 at 9:51
  • @mattnz - I think one of the problems is that you were using ADA and then switched to Java. The two languages that couldn't be more different, and plus you had the added problem, of having over a million lines of code to convert. I agree with Joel you should never rewrite software that already works, but to continue to use ADA, that likely would cause more problems in the future. You had an impossible task, sounds like your managers, didn't listen to their developers. – Ramhound Oct 5 '12 at 12:55
  • 6
    People always like quote that article on questions like this. While a large scale re-write is risky, it's sometimes necessary. Market conditions, maintenance costs and so forth will do this. People don't ride horses even though moving at high speed in an automobile is much riskier. – jfrankcarr Oct 5 '12 at 14:31
  • 1
    +1 for Essentially only a fool would chuck out working code for the empty promises of a new code base. – Dan Pichelman Oct 5 '12 at 15:01
  • @ramhound...Exactly how would continuing to use Ada be a problem. The only thing wrong with it is programmers who have never used it. – mattnz Oct 6 '12 at 7:14

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?
  • I think that's exactly the kind of thing I'm looking for. How can you quantify the amount of time we'd save? Both myself and my team all joined as graduates at some stage, so we've never had the chance to support a product with a fairly sensible architect so it's hard for us to put a number on things like that. The different platforms could be key. The company has this view (may be naive) about our user base growing exponentially and wanting it on iOS, OSX, online etc. So yeah, that could potentially be powerful. – sxthomson Oct 4 '12 at 21:07
  • 1
    @sxthomson - Estimate the amount of maintenance work done in a period of time (a year perhaps). Estimate the amount of man hours needed to do that work, and multiply it by the developer's hourly wage. That should give you a rough, usable, figure. – System Down Oct 4 '12 at 21:10
  • 2
    Also think about risk. Try to quantify the risk of a rebuild approach. Does the team have experience on that kind of project? Hoe accurate are your estimates usually? – MarkJ Oct 5 '12 at 7:07
  • Estimating cost and savings on something like this is very difficult. Most projects I have seen miss the mark with the initial estimations by massive margins, estimating a revamp would probably be even worse. Documenting time taken on common tasks makes more sense. You wouldn't have known how long it takes in a good system but at least you would know that some simple bugs should have not taken that long. Also document bugs that are caused by the design. – Tjaart Oct 5 '12 at 9:46
  • @Tjaart - I hate to sound all Machiavellian here, but if the purpose of the report is to convince the higher ups, then perhaps it being 100% accurate isn't that important as long as it successfully conveys the message? – System Down Oct 5 '12 at 18:27

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

enter image description here

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.