How to deal with a large codebase with no requirements and the responsible person leaving the company soon [duplicate]

Question

i am faced with the following scenario and i wonder if you guys have some tips for me on how to approach this.

One of my colleagues is going to leave the company in a few month and i am ordered to do a rewrite of his application, since the technologies he used are outdated. Problem is, there are no requirements and the codebase is about 250k lines of undocumented source and he is the only person who knows what the application is supposed to do (customers know only the parts they are interested in). I thought about writing requirements with him first while he is still here, since i am doing a rewrite anyway, but i don't know if this is the best approach.

Do you guys have any tips on how to best approach this and how to best use the time he is still with the company?

Thanks in advance and best regards,

peter

Update:

The application is not too complex and the 250k lines are due to the fact that it's all old VBA scripts. I can reduce the locs by 50% at least, just by using modern libs and language features (C#). I am thinking about getting requirements to map out the old application and not use the old codebase at all. As if the "rewrite" is a "new write". I am just wondering if this is a good idea. I know how to deal with legacy code, my question is can i get away with not having to deal with it at all.

Answer 1

I have ported several older VB6 applications to the .NET framework, all of them with almost no documentation, from that experience I can I give you some recommendations. First, let me say, getting rid of VB6 is IMHO a legitimate goal, however, if getting rid of old VBA code (using Excel or Word as VBA platform) is worth the effort is IMHO debatable, since VBA is still well supported for these platforms.

Anyway, if you are really going down this route, I heavily recommend the following points:

1. Dont rewrite, instead: port!

You wrote "I can reduce the locs by 50% at least, just by using modern libs and language features (C#)". By this, you already made the typical error I have seen so many times, even by experienced devs, which will make your attempt fail if you do not change your tactics. Even if the 50% would be true (which is IMHO way too optimistic), you underestimate the time to get these 50% lines of code as bugfree as the original code is. To my experience, if you really rewrite the program from scratch, you will be approximately 10 times slower than by porting the program in a 1:1 manner. See also this older blog post from Eric Nelson, which tells essentially the same. Make sure you also read Joel Spolsky's famous blog post about rewrites.

Porting means, you bring the original source code with as few modifications as possible to the new platform. For this, do yourself a favor and don't use C#, use VB.NET, even if you are surely convinced C# is the "cooler" language. Fact is, C# and VB.NET are almost equally powerful and equally supported by MS, but VB.NET is way better suited as a porting target from old VB6 or VBA programs. Porting will allow you to get most of the program correctly transferred to the new environment with a fraction of new bugs, even if you do not understand every undocumented detail in the old code.

I also recommend to stick back from "modern libs" when there are older, mature libs available which are much more similar to the ones your old program uses now. For example, porting a VB6 GUI to Winforms is by orders of magnitudes easier than to rewrite the GUI using WPF. And libs like DAO or ADO are still available for Windows, there is no need to switch to the very different ADO.NET immediately. If you think switching to a newer library will bring really bring you benefits, do this later - follow the old programmer's wisdom - first make it right, then make it nice.

2. Build a good regression test suite for everything where this makes sense, and build it beforehand, using the old program for producing the reference data!

This can be accomplished even if you do not know the whole purpose of the legacy code. We did this more than once before starting to port, and it saved us so many times from introducing unexpected bugs that I can definitely say it was always wort the initial effort.

3. Plan for porting in small steps, and replace parts of the old program in production by the new one as soon as possible.

With 250K LOC, I am sure there is no chance to replace the old program by the new one in a big-bang fashion. Of course, how to accomplish an incremental replacement depends heavily on the structure of the old program and the use cases which it supports, but in any program of that size, chances are high you can find parts which can be replaced and deployed in isolation. The DotNet stack supports several features to make such a transition more smooth, like easy development of COM components with the .Net language (so you can embed them in your old VBA program as a replacement for the parts aleady ported).

Every part you have successfully ported and brought into production is

• a part for which you do not have to maintain the old and the new code any more in parallel

• a part for which you get valuable feedback from your users about how well it works with the new technology stack, which helps you to port the next portion of the code more correctly and to estimate the remaining work better.

Answer 2

Don't.

While a rewrite due to "outdated technology" may seem like a good idea, it is not!

Every year, a new and cool technology arrives. Few years later, everyone considers it outdated.

Do you want to be one of the guys who change the foundation of their codebase every year? Or do you want to be one of the guys who base their code on well-tested technology, not considering the old age of the technology a drawback?

If there are valid reasons why the technology is fundamentally flawed way of doing things, I can see value in an incremental rewrite of the code. Every time, you need to maintain part of the code, write the part again from the scratch.

Next time, when you need to use external technologies in your project, consider accessing them through a wrapper exposing the minimal required functionality. This way, if you decide the technological basis becomes outdated, you can just rewrite the wrapper. No need to rewrite the entire application.

If some technology is designed to take over your entire application and designed to be hard to access through well-designed wrappers, claiming to be The One True Framework, just say no, like you would say no to drugs. Because The One True Framework isn't, and will result as many problems as using drugs.

So, my advice would be to:

• Explain your boss why a big rewrite is a bad idea.
• Propose an alternative solution, an incremental rewrite
• Explain why the age of a technology does not automatically make it bad
• Explain the benefits of accessing external technologies through a wrapper
• Explain the drawbacks of technologies claiming to be The One True Framework

I'm sure your boss will agree that the rewrite should be made incrementally, and the boss will probably understand that when the code will be rewritten, it will not access the new and cool technology of this year directly. It will instead access a well-tested old technology through a wrapper. So chances are, you probably will never have to rewrite the wrapper due to accessing a well-tested old technology. But if you do, the wrapper is still there and you can rewrite just the wrapper instead of rewriting the entire application.

Just in case your boss doesn't agree, provide a time estimate: 1-10 years for the rewrite depending on your skill level and the complexity of the code. Very skilled programmers can write 20 000 lines of extremely simple code per month, leading to the low estimate. But if you are not as skilled and if the code is not simple, the figure can be as low as 2000 lines of code per month. Actually, when bug-busting, the figure can be even lower, as low as 200 lines of code per month.

Answer 3

Try to find out why they want a rewrite. Be sure to mention that a complete rewrite just to rewrite it does not make sense. It will take a long time, and it will be buggy. Also point out that most rewrites efforts fail.

There are valid reasons to rewrite. If it uses hardware that you just cannot repair, or to change the architecture so to lower the overall cost.

That said, I would try to use the current software as a reference, build write a test suite that I could run against both the old software and the rewrite to confirm that the rewrite is behaving the same.

Ideally, I would want to just rewrite as small of pieces as possible. This way you isolate changes and can continue to provide services while the rewrite is ongoing.

Answer 4

Good luck.

The first thing to clarify with your boss is the time frame involved. Rewriting 250,000 lines of code will take you years. Do they understand this? But then there seem to be things in the application that nobody cares about, there might be features that nobody even knows about, so that will save you time.

Agree with your boss about the time frame. And you will not be able to rewrite but change the app bit by bit. So you can sit with the customer, find their first bit of requirements, replace the part of the app implementing those requirements, and then you do the next bit.

Unless your boss didn’t realise how much work it is, and the project gets dropped.

PS. Some practical remarks:

There are requirements. You have 250,000 lines of requirements :-( I can guarantee that your users will be very unhappy if the behaviour of the application changes.

The "Big Rewrite" - meaning that you write a completely new application from scratch - will end in failure. Take the existing app, and change it bit by bit, so all the time your users have a working app.

Use the time with the old developer to make sure that you can build the application without any problems. Before he leaves, you should be able to take a brand new machine, install all needed software on it, download all the sources, press a build button, and it builds. Same for the deployment process. You don't want to be messing with build scripts that only work on that guy's machine, or worse with build scripts that only exist on that guy's machine, once he's gone.

The most important thing is to figure out how to combine the existing 250,000 lines of source code with modern code, possible in a different programming language, and have them co-exist.

Answer 5

With respect to development, your company seems to have much bigger and more pressing issues than a 250K LOC codebase. The correct things to do in this case are the following:

Avoid the rewrite (from scratch) at all costs.

Try to make your employer understand this is a terrible idea for a number of different reasons:

1. Your question seems to imply you'll be alone dealing with this mess. That is a setup for failure and burnout. An OO codebase with an average of 100 lines of code per class needs 2500 classes to be 250K LOC in size. I doubt a legacy system is OO through-and-through. And as others pointed out, even if you are a top-notch coder you'll still need quite a long time for that rewrite. It can only work if your employer has enough patience (measured in the order of years).

2. You will be asked to patch and update the old codebase while rewriting (because management always says it won't happen, but we all know it does). Due to resource constraints (see 1.) you'll probably "have" to apply these modifications without proper documentation or tests. This will create more problems than it solves and all modifications to the old code base will take more time than you think they will, which will slow your rewrite down to a crawl and impact your deadlines.

3. This old codebase has no documentation. I'd suspect it has no tests as well. This is bad by itself, but once the former responsible developer goes out the door, the domain knowledge goes with them. Any modifications that you do will most likely cause new bugs or regressions, because you don't have the domain knowledge or the security of the test suites. This will contribute to slowing you down as well.

4. It is extremely hard, if possible at all, to accurately estimate the timeframe required for a work of this size. In the absence of an accurate estimate from you, management will most likely try to impose a completely unreasonable timeframe that only makes sense when you aren't looking at the code.

If feasible, ask your colleague to help you build a suite of characterization tests (which also serve as spec/requirements). Proceed with an incremental rewrite from there.

You'll need a separate environment where the tests can be run (don't run characterization tests against production environments!), but the advantage of doing this is that you can:

• keep delivering changes to a single codebase (less context switching);
• acquire the necessary domain knowledge simultaneously;
• avoid committing to an impossible task: you'll be able to spend the majority of your time rewriting and refactoring parts of the application with the help of the test suite. If you get stopped to work on features/current bugs, no big deal. Change the characterization tests and change the legacy code. Once that's done you can continue refactoring, possibly starting with the feature you just introduced or the modules related to the bug you just fixed.

Also, look at the linked/related questions and other answers given where there are references to specific books/articles on the subject (i.e. working with and refactoring legacy code).

Finally, you might want to ask yourself a few questions, for your benefit (and maybe also the company's):

• why would a company allow one single developer to "own" 250K LOC?
• why aren't they trying (or can't they try) to retain this developer?
• why aren't they learning anything from this (indicated by asking another single developer to repeat the feat)?

Those are all red flags in my book. If reasoning with your management fails, consider updating your resume.

Answer 6

The requirements are encoded into the behavior of the current application.

Read through the code and experiment with it, and produce documentation of the current behavior. For everything you don't understand, ask the original developer for clarification, and add explanatory comments directly in the source code.

I know how to deal with legacy code, my question is can i get away with not having to deal with it at all.

No, sorry. Since the requirements are encoded in the old source code and not documented anywhere else, there is no way around using the legacy code as a starting point. You will have to dig into into it and familiarize yourself with it, whether you like it or not.

While the requirements may to some extent exist in mind of the original developer, the human memory is fallible and you will easily forget key points if you try to document the requirements from their memory.

Answer 7

If you know VB, try to convince your employer to let you refactor it first and, after that, both of you will be in better position to know if a rewrite is needed.

Refactoring will be the only way to truly understand what the code does. For it, I recommend you 'Working Effectively with Legacy Code' by Michael C. Feathers.