I joined a company as a solutions architect less than a year ago, with a main task of consolidating, and modernizing legacy code resulting from 90+ company acquisitions over the past 20+ years.

One of those legacy applications, is a desktop application written in VB 6.0 that accesses a SQL Server database and has business logic embedded in the client side. That was the good news!

The bad news is that the production release of this client residing at end users machines, is two releases after the latest code checked in our source control system (that is 5 years gap).

What I did so far

I installed Enterprise VB 6.0 IDE, and attempted to load latest source code and tried to charter the application into main modules, relying on menu items defined in the main form.

I used some sort of a mind map like diagram to list down those menu items, and identified the main function of each of those items, in terms of data access and processing.

Fortunately, 8 menu items out of the 162 items are useless decorations, but the rest points at real business logic and data access.

What I was planning to do next

  1. Identify database tables accessed by each menu item
  2. Identify relations among those tables in terms of triggers, referential keys and possible stored procedures
  3. Build a skeleton .NET web application
  4. Attempt to infer some workflow diagram for one of the main modules of this application
  5. Extract that logic of the identified module into and implement it into the .NET application with hooks to the original database
  6. Convince users to use the new screens provided.
  7. Iterate on the previous steps until all functions covered by he legacy application are migrated into the modern web application.
  8. After all screens and business logic is migrated, I should start refactoring database objects.

My Question

IS the above plan realistic? is it sub-optimal? Any advise on more practical way to deal with this beast?

Thanks and sorry for the long question

  • There are a number of open questions for me: What do you want to achieve? Will the new application have benefits for the users or should it just be easier to maintain? How many lines of code does it have? How well is it documented? Do you (or any other single person that is available) understand the business logic? Are there autonated tests? Generally I am very sceptical about rewriting legacy applications that you don't fully understand. Replacing the functions one-by-one is a good idea however. – Frank Puffer Aug 24 '17 at 19:31
  • Main reason to replace is the gap between released product and code in our source control system, we did receive one request to fix a bug and failed to fix it due to that. Lines of code, never counted really but it should be roughly 100k, no one fully understands business logic(including users), no automated testing and no documentation. – A.Rashad Aug 24 '17 at 19:35
  • Not sure I understand correctly the direction of the gap - are there changes missing in your source control system, because former devs "forgot" to commit them, and the production release is newer than the available sources? Or are there 5 years of commits in the source control system which never reached production? – Doc Brown Aug 24 '17 at 21:26
  • It's the former. We have 5 years of lost code. Production is newer than code – A.Rashad Aug 24 '17 at 22:01
  • Would it be a better approach to ask sub questions in separate posts? – A.Rashad Aug 25 '17 at 13:42

So it seems you are planning to rewrite the original application step-by-step and replace it with a new application. Depending on the application logic, a "step-by-step" approach maybe possible or not, and it could be a sensible approach.

However, for a 100k LOC application, if the new implementation will be roughly of equal size as the old, my gut tells me you should expect a total effort of something between 2 and 4 person years (roughly). Of course, this is just a wild guess, and it will really depend on a dozen factors like the team involved, in the necessity to migrate the full application or only parts of it, in your ability to analyse the unknown business logic and so on. But it should give you an impression about the costs you have to expect, so you or your company can consider if it is worth it or not. You should also be familiar with the arguments in Joel Spolskie's warning against big rewrites, however, this article assume you have some alternatives based on evolving and refactoring of the original source code.

Before you go this route it might be worth to consider some alternatives which could turn out to be more economic:

  • try to track where the former devs are living today and if someone of them might have a archived copy of the actual production source (or at least a newer version than you have). A two weeks salary for a professional investigator will probably be much less than a 2 years salary of a developer, so it might be worth it.

  • analyse how big the actual functionality gap is between the available source code and the current production release, and make an estimation if it may be cheaper to reimplement the missing differences on the available VB6 code.

  • try to use one of the existing VB6 decompilers. Even if it does not produce you maintainable or compilable code, it might help you for doing the former step, or to make the migrating of the old application to

In the end, this boils down to a management decision. Rewriting the old thing might be also a strategic decision to get rid of the old VB6 legacy code. Another key factor here is also how important that old application is to your company, or how important it is that evolvement and bugfixing can take place.

  • 2 to 4 man years for a 100k LOC app? I know that lines of code are hardly a complexity measurement, but spending anything over 2 years on an app having about 100k LOC really seems like your programmers are not very effective. – Andy Aug 25 '17 at 8:03
  • @DavidPacker: sure, code cowboys producing tons of crap can be "faster". But I am talking about quality, production-ready code. Note OP told us the 100k LOC currently does not contain any testing code. – Doc Brown Aug 25 '17 at 8:13
  • .. and, honestly, your statement shows exactly the kind of underestimating bigger software projects which make them fail so often – Doc Brown Aug 25 '17 at 8:20
  • 1
    In no way I am talking about crap code. E.g. me and another developer delivered a greenfield product of about 210k LOC in 8 months (system containing business rules, calculations and also some meaningless CRUD). Since launch the software required one minor bug fix and a few additions the client requested. But that is it. The code is maintainable, fast and as you can see pretty much bug free. So I don't see a point why a 100k LOC project should take between 2-4 man years. – Andy Aug 25 '17 at 11:57
  • 1
    @A.Rashad: the fact there is already a working application makes some things harder, and some things easier. However, if you don't get access to the current source code, and you have to start from 0 again, it is not unreasonable to expect the same order of magnitude for the effort to rebuild it as the effort which was invested to build the application the first time. I recommend also this article of Spolsky – Doc Brown Aug 25 '17 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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