Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Next developing phase of a VBA system

Options
  • 16-06-2008 1:55pm
    #1
    UsedtobePC
    Closed Accounts Posts: 114 ✭✭


    The situation is like this:

    I developed a model for work using Excel VBA with a few userforms thrown in for good measure. The model's purpose is to run a simulation for different sets of pre-defined incremental parameters and deliver a matrix-like analysis of the results. This model was intended for my own use mainly, therefore the code wasn't as clean as you would expect and as it happens in many cases, the more you do the more you learn and now I've realised that the way i did some things was not the most adequate or efficient.

    I've been asked to deliver the next version of this model in order to potentially roll it out to other branches of our company. While no professional system is expected of me as I'm not a developer, some robustness and resilience would be good in order to save myself from becoming a technical support slave to my system.

    The debate is around the following issues:

    a) Do I stick to the principle of "If the code works don't fix it even it is a mess"? Do I build upon the existing code or start from scratch on a clean slate

    b) Should I stick to Excel and VBA? Or is there a better alternative to develop this system? My programming experience is limited to Delphi and VB but I can learn if the language is not totally different.

    Any suggestions are welcome


Comments

  • Options
    #2
    kayos
    Registered Users Posts: 2,494 ✭✭✭kayos


    I used to work in a company where many of the business guys developed their own handy little excel bit's and bob's. Now while the workbooks did serve a purpose the development team hated them for a couple of reasons.

    a) The people that developed the macros/vba etc where not programmers and as a result most of the code was a nightmare to try and support.

    b) Multiple copys of the excel file went to different people who fiddled with the code to make it work the way they wanted. Leaving a total mess of trying to merge the code.

    c) If anything went wrong it was normally the Dev team that got the call to fix it even if they had no prior knowledge to the existence of the workbook in question.

    d) Exception/error handling was poor or didnt exist.

    e) Did I mention the code was a nightmare?

    So long story short clean up your code and lock it down so there wont be 10 different versions around the place.

    I would say code it up in VB/C# but then your entering another world of pain if programming is not your main thing.


Advertisement