8

I was sent out to discuss a system that a certain company is currently using and what should be done with it.

The company manufactures various carton displays. This system was developed to keep track of clients, orders and prices. Lots have happened since the system was created and the system is now, as the manager described it, "locked up" and "problematic", which I translate as "not dynamic" and "unstable".

Some info about the system

  • It was developed around the year 2000
  • Fairly small system, 2-5 users, 6 forms, ~8 tables with average quantities of data
  • Built on early Visual Basic, forms created with the drag and drop design. Interface is basically just a window with a menu and some forms
  • Uses MSSQL database (SQL2005 server) to store data and ODBC driver to query, data was migrated from excel before this system, and before excel it was handled, calculated and written by hand and paper
  • Users work in Microsoft XP environment (and up)

Their main problem is that they can't adjust and calculate prices, can't add new carton types etc, correctly anymore because they can't (or rather, they don't know how to) touch the data on the server.

I suggested 3 possible solutions

  1. Attempt to patch the current system
  2. Create a fresh new interface (preferably similar environment, VB.net or VB based)
  3. Bring it back to an Excel solution, considering it is such a small system

There might be more options, but these are the ones I could think of.

My questions are

  • What should I recommend and why?
  • What is or could be the pros and cons of these alternatives?
  • Are there other (possibly better) alternatives?
Improve this question
11
  • 3
    You cannot decide how badly broken the current system is until you have documented the database schemas.
    – user1249
    Commented Mar 20, 2012 at 11:15
  • @ThorbjørnRavnAndersen That's true. I have only peeked at the database. Judging from the age it was created, I'm going to assume that it's really really terribly designed and is in need of first aid... or surgery.
    – ShadowScripter
    Commented Mar 20, 2012 at 11:21
  • 1
    Do you know who wrote the original system? Was it an inhouse effort or was it contracted out?
    – maple_shaft ♦
    Commented Mar 20, 2012 at 11:22
  • 7
    Don't do that. Tell the client that the state of the database is crucial to the cost of the various options, and should be done regardless of which option they choose. Even for a rewrite from scratch they most likely want their data ported over.
    – user1249
    Commented Mar 20, 2012 at 11:23
  • 4
    Developers like to default to "rewrite from scratch" and refactor only when necessary. I'd rather default to "refactor gradually" and only rewrite when necessary.
    – quant_dev
    Commented Mar 20, 2012 at 11:28

6 Answers 6

Reset to default
5

Something with only 6 forms and such should be easy to rebuild on a more modern framework. I've worked with migrating VB6 projects that had around 200 forms along with dozens of classes and database tables. It doesn't sound like you're looking at anything that messy but looks can be deceiving.

I'd have to analyze the code, the database and business requirements to say if rewriting or refactoring the existing code base would be best. Given what you've said, I'd lean toward a rewrite. But, there could be hidden difficulties that you don't see right now.

Improve this answer
2
  • Given its small size, I agree. At a glance, it doesn't seem too complex either. Judging from the answers, a rewrite does seem most appropriate. I'll take a closer look before making a final decision though. Thanks for the advice! :)
    – ShadowScripter
    Commented Mar 20, 2012 at 11:55
  • @ShadowScripter I'd take a look at writing it in a better language than VB while you're at it. Check out the open source lazarus project.
    – Spencer Rathbun
    Commented Mar 20, 2012 at 17:51
5

I have slightly different advice the most of the responses so far.

Attempt to patch the current system

I would at least learn the current system well enough to explain to the client how to use it. I would take this time to explain the flaws in their current system, avoid negative words, just tell them what it cannot do even if all the known bugs were fixed.

Create a fresh new interface (preferably similar environment, VB.net or VB based)

After you have learned everything you can with their current setup. Provide them with options, if you can address their concerns with their current system, there really isn't anything wrong with their current system. The only concern of course is that Visual Basic 6 support might not exist in 5 years.

Another concern is the way it communicates with the database. Microsoft is slowly getting rid of some of the older ways to communicate with its database products ( Access, MSSQL ) so the way you interact with those products will determine if the solution can be used on Windows 9, and Windows 10 in the future.

This answer entirely depends on the fact they have the source to the application itself. If they do not have the source then it will be hard to address their concerns, fix the current major bugs, or even make it a tool they can actually use.

I don't feel there is anything "wrong" with a Visual Basic 6 application, besides the fact, its support for future versions is unknown. Even today with Windows 7 and 64-bit operating systems its getting harder and harder to support. This is a major reason a rewrite into a modern language with proper 64-bit support might be a good idea.

If they don't have the source at that point a rewrite is really their only solution.

Improve this answer
2
  • Could you cite a reference to "Microsoft is slowly getting rid of some of the older ways to communicate..."? Would like to read more about it.
    – ShadowScripter
    Commented Mar 20, 2012 at 17:40
  • @ShadowScripter - For instance the Microsoft.Jet.OLEDB.4.0 Provider in order to access legacy Access database files is not supported when the process is not a 32-bit process. WinRT might also change how we connect to these Microsoft products. I forget where I read about a future change, my understanding is after MSSQL 2012 Microsoft will only support specfic way of connecting to it also. This of course in the context of the providers built into Windows and its development offerings
    – Ramhound
    Commented Mar 21, 2012 at 18:05
1

Rewriting the interface is an excellent option, given that the system is relatively small. Advantages are -

  1. Improved stability (assuming you do it well!)
  2. Improved maintainability
  3. Modern interface

The main disadvantage is that it will still probably cost a fair bit more than hacking the existing code.

Improve this answer
1
  • Rewriting the interface is what I was leaning towards as well. And to be honest, I'm not sure where I'd begin with the old interface, judging by today's standards, it's just so... bad all around.
    – ShadowScripter
    Commented Mar 20, 2012 at 11:26
1

I would also tend to rewrite, but you need to be 100% sure you understand the current functionality fully as well as any functionality which is broken, missing or inadequate. The latter two are important as you mentioned adjusting and calculating prices. Do you fully understand the consequences of adding this feature?

I once worked on what was supposed to be a "website", but was in actual fact taking over a custom Access based CRM style tool from the late 1990s and bringing it into the modern, web based, world. The original developer was long gone, the Database had been modified umpteen times, original documentation was thus out of date and no one really understood how the system worked. But they knew how to use it, just. Probably 80% of the budget for this project went on three things:

  • gathering requirements
  • understanding the current system
  • coming up with a meaningfull database schema for how they intended to use the software

The project was, financially, not a success!

Improve this answer
1
  • I hear what you're saying: before I make a final decision I need to be fully cognizant of its current failings, functions and purpose. It's not like I want to go all in, with guns blazing, screaming All right, let's do this. LEEEEEEEROOOOOOOY...! :P
    – ShadowScripter
    Commented Mar 20, 2012 at 15:27
0

Another option could be a compromise between rewriting the whole thing and hacking the existing app.

Give them the new functionality in a new application built from scratch.

This could potentially be easier to do, and not cost as much as a full rewrite.

Once this has been done and they are happy they can add/update data, it opens the doot ro a phase two could be replacing the existing funcationality in the new app.

This might be a more palatable approach.

Improve this answer
1
  • 1
    I suppose that's a good idea, but if phase two never happens, they will end up with an old separate application that is dependent on the other new application, leaving them with two applications and double the trouble.
    – ShadowScripter
    Commented Mar 20, 2012 at 11:43
0

Rewrites often have a tendency to run out of budget... Badly.

But having a modern skeleton for the application, might be a good investment, especially if no one knows how old system works, and if things break as soon as you start touching them.

Also, VB6 is bad for support. When you'll need to find specialists in 10 years, that will be pretty problematic.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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