An interesting question was posed to me earlier today. Why should I bother upgrading my Excel Spreadsheet application to a .Net Desktop application? Maybe the same question, or something similar has occured to you. Let’s see what we can come up with…

A few things come to mind off the top of my head:

What happens when you get hit by a bus?

As developers, we all hear the question posed, or the scenario bandied about… “If you get hit by a bus, your coworkers should be able to carry on!” Unfortunately, Excel Workbook applications seldom exhibit the hallmarks of code that can be easily picked up by a new developer. Whether it’s a Cell that holds random information for calculation later (no comments embedded, of course), or some VBA script that is pulling information from three different worksheets to generate a calculation – Excel is not the best tool for building robust, long-standing applications.

Maintenance

Which of course brings us to the issue of maintenance. Of course your Excel application runs completely perfectly, and never needs any bug fixes. And if it did, you know exactly where to go to fix them! We’ve all been there. However… what happens when you want to add a feature three months down the road? Six months? 24 months? What happens when you upgrade to a new version of Excel and discover – OOPS! – your macros are significantly slower in Excel 2007 than they were in 2003???

Performance

Of course, if we’re going to talk about performance, we should mention the benefits of using compiled code (.Net) versus interpreted code (VBA). Compiled code is only reduced to machine language once, and can be run any number of times. It reduces the performance cost of that reduction. Interpreted code, on the other hand, is not “compiled” until run time. This can cause issues such as type exceptions that would otherwise have been caught by a compiler.

What does .Net offer?

The .Net framework offers a number of things! First off, the current generation of desktop UI is the Windows Presentation Framework – WPF. This framework allows robust, modern, nice User Interface development, and also allows the developer to focus on keeping business logic separate from the UI (not POSSIBLE in Excel!!!). By utilizing modern WPF Frameworks such as the CODE Framework, I would recommend developing a new UI, while leveraging the existing knowledge and expertise which went in to building the original Excel Spreadsheet.

In addition, I would use a Service Oriented \ Distributed Systems Architecture in order to ensure that your Business logic is completely separate from your User Interface.

What next?

Here’s the best part… By developing your Desktop application with the future in mind, you can expand quickly in to future User Interface areas such as Windows 8 Store Applications, Windows Phone 8, and other mobile technologies.

As you can see, we’ve gone from having an Excel Spreadsheet, locking us in to a specific UI \ Business Tier \ and Data Store – to the point where now we can substitute any tier at will. This is a much better position for you to be in moving forward, both for your business, and for you as a developer!

What are your thoughts? Would you keep the existing Excel Spreadsheet? Move on to something different? Let me know in the comments!