Legacy code, legacy tools - what to do?

Question

Hi,

I have a bit old project that I would call legacy.

Some characteristics of it are:

1. It is a working product (for about 3 years) and is under continuous development.
2. Code-base is pretty large and includes (CS, SQL, ASPX, Jayrock, JS/HTML/CSS etc)
3. Platform is .NET 1.1.
4. IDE is Borland C# Builder 2006 (what a ...).
5. Other tool is Enterprise Core Objects 3 (for .NET 1.1) (Model Driven Architecture - O/R-M from UML).
6. Additionally Telerik RadControls are used.
7. Mostly one active developer.
8. Lots of tests for Business Objects, but the UI (WebForms) is not testable ATM at all (no MVP/MVC applied etc).
9. I have to accept that code quality is not "the best" and remains on the mark "Good enough" (so this is NOT the main reason to rewrite all from scratch)

The problems with this project are:

1. .NET 1.1 - the platform is not "active" anymore.
2. IDE - struggling with it all the time. Just pain to work. Bad tooling support, any refactoring is basically made by hands.
3. ECO3 framework - a LOT of effort to move to ECO5 (and thus .NET 3.5).
4. Migrating from ECO3 to NHibernate (preferable) will take even more time (as all the logic/tests should be rewritten).
5. The ECO3 heavily relies on IDE, so it is nearly impossible to change IDE ONLY.
6. Generally migration to .NET 3.5 will take a lot of time (especially for 1 dev only).

I would like to hear any recommendations/tips on how to deal with this project.
Should I continue working in that environment?
If NOT, what is the best way to migrate the whole project BUT within days (delay in weeks is too long ATM). Yes, I understand it will pay off later, BUT I can't do that NOW.

Generally any suggestions are welcome.

Cheers,
Dmitriy.

Answer 1

Well, given your available time span, I'd suggest you keep the code and use it. But whatever you're changing or making new, make sure you write the code in the best manner you can.

Usually, when you do this, the project gets better as time goes by, 'cause once in a while you'll probably be changing some "dirty" part, and hey, that's one less "dirty" part in your code :). In the long term, you should have a cleaner and better written code.

As for IDE changing, I tend to agree with Martin. it shouldn't be THAT hard to migrate to another one. But I'd suggest doing it after this first small time span you mentioned (unless you're a risky guy).

Answer 2

If the code is only three years old, it's not legacy yet. It's IMO wasteful to redo things in a different way every three years (or even every five years).

OTOH, it should be possible to replace the IDE with a different one with comparably little effort.

Answer 3

I'd migrate and refactor slowly, in small steps. My suggestions, in order, would be:

• Migrate to a "better" IDE (one that you like - probably Visual Studio?)
• Migrate to using .NET 3.5 features. Refactor as needed to take advantage of newer features, like generics and LINQ
• Start updaing your business logic as needed

Other than changing the IDE, everything else can be done in very small steps, on small portions of the codebase, via standard refactoring practices. No all out rewriting should be necessary.