I'm working on a code base that dates back at least 15 and possibly as much as 20 years, where the older code is still functional but includes thousands of JSPs full of Connection, PreparedStatement, and ResultSet objects, as well as hard-coded SQL, to manage data access.

Yes, it's about as painful as it sounds ... but my question specifically is that, since it still works, what are all the other drawbacks than simple functionality?

I want to write up a proposal to submit to the owner of the company so he'll pony up the cash to get this all updated to modern standards. I can think of many of the more obvious issues, but from a business perspective, what looming crises are on the horizon that can only be avoided by turning the ship now?

[Edit] To clarify, I'm not looking for advice or suggestions on what technologies to use. As a question of software development I'm looking for a short list of issues relevant in 2016 that make good business sense, to use as part of the proposal. For example, what are the "hidden costs" to this architecture, what are the vulnerabilities and potential damage from failure, etc.

  • 4
    There isn't really a question here. You might find some insight at this blog post, however: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i. Personally, my philosophy is to get it working and out to market, and if/when your product explodes in popularity, you'll then have the money and reasons to do it right, if you're so inclined. Commented Dec 27, 2016 at 23:10
  • 1
    Also, note that what is considered modern by today's standards will be old, obsolete and antiquated five years, five months or perhaps five minutes from now. So you'll be doing it again after some time passes. Commented Dec 27, 2016 at 23:15
  • 1
    That should probably read "every answerable question about software development." And no, we haven't forgotten our question-asking standards just because the tagline has changed. Read Joel's article; it directly pertains to the question you asked. Commented Dec 27, 2016 at 23:16
  • 1
    Just go through your issue log and generate a list of all the problems that the legacy code has actually caused and explain how your approach would prevent them from happening again. You do have actual evidence that the existing code is causing problems? And when you submit the request for funding to refactor the code, also include, in writing, how much your existing rates for project maintenance will be reduced.
    – Cerad
    Commented Dec 28, 2016 at 1:59

1 Answer 1


The answer your looking for is mostly regarding security and user experience. I've managed hundreds of older applications and it is never a good thing to have something in production that you dread or do not fully understand. The way I see it:

1 ITS OLD, TECH IS MEANT TO BE UPDATED. Legacy software is often not only a pain for the developer/maintainer it is also a huge money pit. Owners of companies end up paying far more to maintain/fix things as they break in older legacy applications because of all the testing/precision guesswork/trial and error that often comes from older hogpoged applications. Its often a much better investment to rebuild the app using current standards. Not only will it be easier to maintain, but both owner and developer will have a certain peace of mind where you know if something breaks, you can easily fix it, instead of spending days reviewing your old outdated code and then old outdated ways of fixing it. Often times you'll find libraries that are need that may simply not exist or have been pulled from websites.

  1. SECURITY. This is a big one. Legacy software is often insecure and hard to patch. Security practices change CONSTANTLY, and it is something that HAS to be kept up with. Many legacy applications can reference old/broken/unsecure methods or libraries that can give hackers free access to your database, and finding these issues is incredibly difficult, fixing them, even worse. Case an point is a customer of mine ad an old vb.net application. There was security flaw allowing someone to break into website by injecting directly into a datepicker app function. Newer technologies are often built with security in mind and are much easier to test and maintain the security side. It is easier to prevent SQL injection, You can get SSL certs much easier, and if a problem does occur, you can usually easily search Stack or other resources to find a fix quickly. On legacy software.. you could be looking for days for the issue, and days for the fix if one exists, or you may end up dedicating alot of time in money fixing something that isn't worth fixing. Ask yourself this - Can you really afford to be hacked? Would you lose everything? Would you lose days of work? Is knowing that it could happen any time for any reason okay with you? Most owners would rather pay a little now, instead of alot later.

  2. USER EXPERIENCE/PRODUCTIVITY: Newer standards and languages are faster, more efficient, and provide a generally better user experience. Not only do pages load faster, work better, and are more secure..but users are able to be much more efficient, allowing the company to save time and money on slow webpages,random crashes,quirky behavior. That kinda small stuff has a HUGE impact on the bottom line.

  3. DEVELOPMENT OVERHEAD: Newer standards are designed to make it easier/safer for developers to build, maintain, and deploy applications. Not only is easier and does the code make more sense, a developer is much more likely to get useful information or help when researching or trying to find ways to fix the application should problems arise. Newer code allows both developers and management to sleep better at night.

  • Thanks! Could you perhaps expand a bit on the "user experience" issue? What exactly can't be done with older architecture, etc?
    – Andrew
    Commented Dec 28, 2016 at 1:10
  • Well, that is pretty specific to your app - I would take a look at your apps performance, layout. look for anything that could be put in different places, anything that is slow to load, hard to do, or anything that could be sped up by making some changes to the page or ap Commented Dec 28, 2016 at 2:54
  • Thanks for your response. What about something like "it makes it more platform-dependent" which means it's more difficult to implement cross-platform responsive design, or to build a mobile app off the same code base? That kind of thing.
    – Andrew
    Commented Dec 30, 2016 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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