I\'ve been working on a software project mostly solo for over 5 years. It was a

Question

I've been working on a software project mostly solo for over 5 years. It was a mess to begin with (I am the third or fourth developer to be working on it), and although it's less of a mess now it is still incredibly disorganized. The rate of progress in getting it under control is glacial and I'm starting to feel despondent over the state that it's in. How do I really start fixing it?

Project specifics: It is a sales program written almost entirely in Visual Basic Classic (VB6) with a MySQL back end and a reporting engine written in C#. The C# reporting module is a joy to work on, it was only just written in the past couple years and before that all reports were done in Crystal Reports 9 (yes, we still have some reports that rely on it).

The actual program itself, however, is a complete disaster. There are not quite 90k LOC total, and about 10k lines of comments (mostly not documentation, but old code that's been commented out). 158 form files, and 80 module files. I have no idea how many of those are actually used, because some features of the program are simply deprecated and (uh, sometimes) noted as such without having the associated code removed from the program. I would guess that only 50% of the code is in actual productive use.

I am afraid of touching a lot of the code just because I am not sure if I'm breaking something that one obscure client relies on, it's happened on more occasions than I can count. It's like there are landmines strewn throughout the code.

There is not really any structure to the project. It is not object oriented except in the few places I have had the patience to reform so far. If you need to get data on a form, you instantiate a database object, declare your query right there in the function, execute it and do what you will with the dataset.

When I began working on the project there was no source control in use. I tried to encourage the other people I was working on to use it, but I was the new guy and my attempts to get people to use subversion all but failed. The company's lead developer finally caught a mercurial bug in the last couple years and he's made sure that all developers do use source control on all projects now, so at least that's some progress.

I think if I was able to work on reforming the project full time I would be able to make decent progress and maybe even have an estimate for how long it would take me to fully makeover the project, but it is in active use and I am constantly being asked to put out fires, fix bugs, add features, etc. etc.

So how do I start to really fix this project? Try to tool VB6 with another language? Try and rewrite the program in my spare time? Or is this completely hopeless?

Explanation / Answer

Now that it's in source control, you can get rid of the commented out code.

I started here in a similar situation (80KLOC VB6 app with no source control, no real structure, almost everything done in event handlers).

In about 2 years on and off I've gotten more than half converted to C# (usually when significant new features are required). All new C# code has unit test coverage. It definitely takes way more time to convert to C# though. If you're not adding significant new modules, I wouldn't go down that route.

One thing I did was create a rudimentary data access layer that auto-generated itself from the database. That at least caught problems where a table column name changed and I didn't find all the places in the code. Also, I've slowly moved the business logic into modules, out of the form event handlers.

I, however, had the advantage that the application was only internal. Since I only had one site to deploy to, I could take some bigger risks than you could. If I made a mistake, it wasn't usually a big deal to fix it. Sounds like you don't have that luxury.

I really think your best bet is to take the following approach:

Learn every bit in excruciating detail. This makes it less likely you'll break something inadvertently.
Refactor mercilessly to improve separation and structure, but don't try to shoehorn a new methodology like object-oriented programming in there, since VB6 just sucks at it.
Treat it as a learning experience. How would you know a different way is better if you'd never seen the inferior way?
Don't bother rewriting in a new language/framework/platform unless you have a major module to write. Even then, consider carefully.
Remember, the goal of the program is to be a product that makes your company money. It doesn't have to be a flawless work of art (and I'm a perfectionist so it's really hard for me to admit that). Sometimes it's better to embrace pragmatism.

There are supposedly a lot of COBOL programmers out there maintaining massive amounts of legacy code. I doubt they're all madly working away at rewriting it in some new language.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.