Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company has a large software application written in C++ Builder 6. I am a junior developer only one year out of college. My question is:

  1. How much technical debt are they in? What are the hazards of working in such an IDE that is no longer supported?
share|improve this question

closed as primarily opinion-based by Martijn Pieters, Corbin March, Glenn Nelson, MichaelT, gnat Sep 6 '13 at 3:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This is impossible to answer without knowing the codebase – jozefg Sep 5 '13 at 20:09
Are you supporting a legacy system? Do you need features in new tools, or would it just be nice? Are there significant problems with the current tools other than their age? Does this product generate a lot of money with little effort or is your team constantly fighting uphill for the smallest of features? – Ampt Sep 5 '13 at 20:14
I'm sure someone will be able to help enumerate risks of using a deprecated IDE without access to the codebase. – onezeno Sep 5 '13 at 20:15
@Ampt The product is freely given to customers to support hardware that the company manufactures. The major concern is simply the age of the tools. For instance, what are the security vulnerabilities? – onezeno Sep 5 '13 at 20:24
How much actual development is occurring? Is this software that has a large development team adding new features, or is it software that gets a bug fix or two every few months and is otherwise completely stagnant? – Steven Burnap Sep 5 '13 at 20:58
up vote 3 down vote accepted

First of all, most people consider the "technical debt" of an application to only encompass the quality of the code itself, not its associated tools.

The biggest risk of using a deprecated build environment is that the longer you use it, the higher the risk you won't be able to fulfill one of its system requirements. For example, if your compiler won't run on Windows 7, you're stuck running on XP. If you go long enough down the road, you may not be able to find new computer hardware that will run XP, so when your hardware dies, you're forced to upgrade your build environment as well, and the timing may be extremely inconvenient. Likewise if your application itself can't run in newer environments.

That being said, it might take a long time to get to that point. I once had to port a BASIC application that ran for 20+ years on its original hardware. The company was forced to update because they could no longer find a source of ribbons for the dot matrix printers that computer required. Until that point there was no reason to incur the expense of porting it. Don't assume that just because something is old it necessarily needs replacing.

As far as security vulnerabilities go, there is one known vulnerability for that compiler, and it's a fairly minor one. To even be exploitable would require very specific uses of the sizeof operator, and some cracking effort targeted specifically to your application. To be worth exploiting, your application would have to either run in a privileged mode, like a server, or process untrusted remote data, like a web browser. The chances of this hurting you are extremely small. You're far more likely to introduce your own vulnerabilities, or link to vulnerable libraries.

In other words, eventually you will most likely have to update your build environment, and it's okay to plan for that contingency, but unless you're already having system requirements problems it's not an urgent issue.

share|improve this answer
  1. This is impossible to answer without examining the code. Clean, maintainable code can be written in many different programming languages. Just because an application was written in Foo does not inherently mean that it is ridden with technical debt. Some languages provide semantic structures that help enforce good code, but bad code can be written in any language.

  2. Have a look at the following P.SE questions to gain some insight on whether refactoring is an option for you or not.

share|improve this answer

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