We are a group of enthusiast engineers who are developing a series of application using Excel as our front end. We are using VBA but plan to start doing in VB.net. Some people in IT have questioned the wisdom of using Excel as a platform because it crashes, it's unsafe, difficult maintain, slow, etc.

  • 4
    For what sort of application could Excel possibly be a suitable platform? It's spreadsheet software. A macro to automate spreadsheet work, sure. Something deserving the term "application" on the other hand... – user7043 Jul 10 '14 at 22:45
  • 2
    Excel wouldn't be my first choice. For one thing, you need an Office license on every computer. For another, Excel is really domain-specific. – Robert Harvey Jul 10 '14 at 22:58
  • For what it's worth (which is nothing at all) the two first programs I ever wrote were excel macros. They were, respectively, an automatic sudoku solver and a one-function, O(2^n) Connect Four game. No one was able to beat the AI on the second one (not that many people tried). – abl Jul 10 '14 at 23:05
  • 4
    @delnan, I think you would be surprised by just how much of business is run on spreadsheets. If I had a dollar for every project I'd worked on with the mandate to "do what we do in Excel" I'd have ... well, enough for a nice lunch. – Michael Green Jul 11 '14 at 0:11
  • Excel can be the jumping off point for a whole range of technologies. My blog demonstrates the breadth of possibilities. exceldevelopmentplatform.blogspot.com However, for the enterprise I'd recommend putting business rules in Python or C# components and calling into them from a thin VBA layer. Also VBA should probably be reserved for worksheet and GUI logic. – S Meaden Aug 14 at 13:31

If the end product that the users want is tabular data that they can edit or perform ad-hoc analysis on, then developing in Excel may be suitable or even advantageous.

The last Excel application I wrote was in a DNA sequencing lab. The application queried an Oracle database for a list of experiments to perform, organized the needed primers into 96-well plates, generated the primer ordering form, and created the table that was the input to the robot that performed the experiment. I personally wouldn't have picked Excel to do any of that, but the vendors required a spreadsheet as their order form, the robots could read Excel files, and the lab techs loved having spreadsheets to organize the thousands of experiments they had to run every month.

All that made Excel a reasonable choice for that task, but be wary of having a hammer and going in search of a nail.


Have a think about how you manage all the other stuff that goes on around projects that isn't programming. Source control, release management, merging changes from multiple developers, code reviews, testing, bug fixing, controlling user access to data & their ability to change that data, data quality management, storage backups, disaster recover etc. etc. If you can manage all that in Excel / VBA then I would count it as a "strong development platform".

So is Excel right for your application? Do you need the other things that Excel offers - user manipulation of the results, user-defined formatting and graphing, the ability to embed into Word documents etc., is your user community tied to the Office look and feel and resistant to change. If yes then Excel, else no.

Finally, is Excel right for you right now. I'd suggest you take an Agile approach to this. You think Excel might be good. Run with it for now. Get a couple of iterations together and then have another think. It provides an out-of-the-box user interface, some input validation, elementary forms layout (which will let you prototype a "real" application). All things you will need but won't have to learn right away if you use Excel. As you move your code to .Net you may discover a different UI will suit better. Arrange your code in proper problem-related classes (rather than tool-related code fragments) and you should be able to re-package easily and call it from any front end you choose.

As for the problems your IT group lists, they're all true, and they will be true for any software that anyone writes, to a greater or lesser extent. To my mind the question is whether this alternative is any more or less buggy, safe, maintainable and suited to the known requirements than that alternative.

We use Excel extensively in our business, but in a targeted way where we draw on its strengths, not as a general purpose platform.


Agree with Charles. There are limited conditions where programming in Excel first is a good idea. I've haven't run into one yet. It is almost as easy to create the .NET app first and use the Excel engine for your output. Calculations / Formatting or anything you can do in VBA can be done using .NET and the Excel interface. VBA and VB.NET have the same base language but the methods of getting from A to B can be very different and in some cases radically. Initially, when I started programming in VB6 and using VBA, I did some programming in Word, Access and Excel using VBA. I found it somewhat cumbersome in comparison to just creating the VB6 app to do the same thing.

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