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.
closed as primarily opinion-based by Robert Harvey♦, user40980, gnat, mattnz, Bart van Ingen Schenau Jul 11 '14 at 6:16
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
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.