Disadvantages of bigger project in VBA

Question

i am new in project for company that have bigger enterprise/accounting system based on Visual Basic for Applications (VBA) in Ms Access 97. This application is still alive, they

Answer 1

This is very subjective. VBA has a bad reputation but that's only because it was designed to be a very accessible scripting language for programmers that didn't have a lot of skill. The ultimate irony of using a language like that for a big project is that it takes a very skilled programmer to not let it spiral out of control. Like somebody that understands what you have to do from the get-go when the language doesn't support namespaces, you'd better come up with a very good naming convention from the start.

I can guess why you are asking this question. And the answer is that it is extremely difficult to throw away years of work just because the language isn't appealing. The lodestone for this is Netscape version 6.0, well covered by Spolsky's "Things You Should Never Do".

The best cure for discovering that you work for an employer that has brown-field products is to find another one.

Answer 2

There are no real answers here from anybody who demonstrates extensive experience with Access, so I'll give my answer:

1 Is VBA even designed for bigger projects?

Define "bigger projects." In general, I'd say no, but I'm thinking in terms of Enterprise-wide apps. But the question here is not whether VBA can be used, but whether Access is a front end appropriate for apps of this extent. The biggest drawback with Access (aside form deployment issues) is managing the project because source control is not as easy as with other development platforms.

But you don't really give an idea of how big the app is. Is it used by hundreds of people? Or does it just have hundreds of sub-components? That is, is it big in terms of complexity or big in terms of number of users?

I think, that its more likely for macros and simply functions which extends Access funcionability.

As I said, you're asking the wrong question. The issue is whether Access is an appropriate front end. If it is, then VBA is the language you have to write it in.

As to "macros and simple functions" there's a terminological problem in that Word and Excel "macros" are generated in VBA, which makes many people think that VBA is a simple language. VBA is, in fact a SUPERSET of VB6 (not a subset) -- VBA has MORE functionality built in than VB6 itself. With Access, most of that functionality is specific to interacting with databases, and because of that is very useful (compare an Access bound form to a VB form, for instance).

In general, though, the Access philosophy is one in which you begin with building objects interactively, point-and-click, and then add code only when the default behaviors are not sufficient. VBA allows a great deal of flexibility in that it can interact with any tools that have a COM interface. It's basically unlimited in what it can do (though certainly there is a limit to what is practical).

2 Will be better to convert the application to .NET winforms/wpf

"Better" for what purposes? If you have a working application, you really have to consider the Spolsky/Netscape effect (cited above). Certainly you might get better code management, but at the cost of having to maintain a lot more of it. On the other hand, if you have inhouse expertise on that development platform and none with VBA, then there's going to be a bias towards migrating to the development platform that's more suited to your particular developers.

But it's not really an issue of "better," which can't really be determined without knowing all the issues and personnel involved.

3 Can work more developers on VBA project?

With Visual SourceSafe you can have multiple developers working on the project. Or, you could automate your build using Application.SaveAsText/.LoadFromText and use the CVS of your choice.

But in general, I'd say that Access is much better suited to a single-developer model.

4 What are the worst disadvantages of VBA code running in hosting program against stand-alone application?

I have no idea of what this question means. Many people have the crazy idea that the workset for an Access front end is bigger than the workset for a VB6 app doing the same thing, but it's actually not true. I would expect .NET is about the same (if not an even bigger workset, since things always get bigger and bigger as "progress" marches forward).

The biggest disadvantage of Access, in my opionion, is the problem of deployment, where any users who need multiple versions of Access can have lots of problems. The SageKey install scripts are designed to fix that, but they are kind of ad hoc -- they fix problems when they come up, so if you have a deployment environment with problems they haven't yet encountered and handled, you're out of luck. But they do cover most such circumstnaces.

5 Is possible to run unit tests or any similar technology?

I don't believe so, but then, as an Access developer, I probably don't have any really good idea what unit testing really is. Most of an Access application's code is user interface not algorithmic programming, so it's NOT going to be easily testable, I'd think. Whether this is an issue or not depends on the nature of the project and the type of testing that is believed to be necessary.

For an accounting app, you really do require a high level of reliability, and as I said in a comment elsewhere, if somebody interviewed me for a potential project to build an accounting app, I'd recommend they not build it from scratch, regardless of the chosen platform.

Answer 3

1. In theory no - it was designed mostly for small-amount-of-users apps. Your example shows it can be used in larger projects.
2. The resulting system (if converted correctly) will be of better quality. But, as always in business, you have to mind the cost of conversion.
3. Yes they can, but it is more difficult, as there are not many source control systems compatible with Access modules (Beyond Compare should work, afair)
4. Performance, scalability etc. etc. I can think of no advantages, it's simply that VBA is not really good for larger systems (imagine that you would like to have some web reporting, or other functionality which is very difficult with Access)
5. It's possible - but fully manually

As with all technologies, almost everything is possible using Access - but you have to mind the cost of maintaining such systems. It is not a question IF you will convert, but WHEN you will have to.

Answer 4

1. Almost everyones got a VBA horror story, where an access or Excel app was running in large scale environments, but as ufoq says, at some point you will have to make the switch. Is it necessarily the VBA that's causing the problem though, or is the Jet engine that Access runs on? The access GUI can be used in large scale applications with a SQL server backend.

2.Most Probably, though that obviously depends on the skill of the developer.

3.This would be a problem as everyone would be working on the same file. So yes, >NET development supported by version control would be better for more developers

4 and 5. See ufoq's answers

Answer 5

You probably need to ask the company a few questions first:

• why wasn't the project migrated to newer versions? Staying with one version implies wanting to kill the project in the long term. If it was not worthwhile to keep up with current versions, there probably also wasn't enough resources to maintain the application properly. This is most likely to kill a migration traject. Having to make up for 10 years of insufficient maintenance is expensive.
• building a large system in VBA was a bad idea 10 years ago just as it is now. Why should you believe management is going to make better decisions now?
• the correct way to handle this kind of legacy is to make sure that the maintainers reach their pension age just a few months after you stop using the software. When does management expect that to happen? Getting qualified people will become more and more difficult, the more out of date the technology becomes.
• migrating these kind of systems can be awfully expensive. How willing is management to make the investment now, when they have not been willing earlier? You need to come up with a strategy where you can make very small steps and use the newly written software already. Do not use plain .net/winforms/wpf. Make sure you invest some time in finding at least an application level framework. A totally different approach would be to use tooling like MOOSE to reengineer the solution.

Answer 6

1. No. It is Visual Basic for Applications and it does exactly that, provide an interface for COM objects and macros.

2. I would start moving towards WPF as it will be the more future proof of the two choices, but if your stuck supporting machines not yet running XP Sp2 you'll need to use WinForms (though I highly doubt this scenario). VB.Net might be a good starting point for all the useful dodads in the Microsoft.VisualBasic namespace.

3. Yes, start breaking out the solution into seperate .vba and .mod files and introducing source control. However, by this point you should consider migrating your developers to VB.Net or C#.

4. VBA is pretty much stuck on single threaded execution. Visual Studio Tools for Office when used in conjunction with VB.Net and C# is missing functionality present by directly using VBA.

5. Sort of. See VBAUnit.

Something to keep in mind is that VB6 hit end of life in 2008, and VBA is still included for Office 2010, but it is being encouraged that developers use VSTA instead. Administrators used to use batch files and VBA scripts, but Powershell is slowly but surely replacing that type of implementation. Basically, VBA will still work, but there are newer (and probably better) ways of doing things (that wont hit end of life soon).