In the build versus buy debate, which has many different considerations for software development companies, I generally lean towards the buy option. The cost to develop, support and maintain your own component code is often far greater than buying the component if available. Purchasing the code for a complete application with the intent to extend has completely different arguments and implications.
One of the first tasks was to write a new installer. The reason for the new installer was to implement it using WiX so that we can have full control over the installation and bring it in line with the rest of our application installers. I have built many installers and once I had the information I needed, this task went smoothly. I will talk more about installation creation with WiX soon.
This particular application is an Excel Add-in, written in VB.NET. One of the issues that was raised has been is the poor performance of the add-in. Doing a refresh from the data source takes almost 10 seconds. Some VBA code was written by the consultant that raised the issue to attempt to determine if the bottleneck was with the add-in or the data source. The VBA code returned the same data set almost instantaneously. Of course, the add-in performs more on a refresh than just what the VBA code did, but difference is unacceptable.
It was time to dive into the code. Running performance analysis over the application quickly pointed to the violating method. Unfortunately, the method was over 700 functional lines long! Before I could make performance improvements, I needed to understand what the code was doing. Before I could understand what the code was doing, I needed to refactor the method into manageable-sized methods. With the wide scope and reuse of variables, and the lack of unit tests, this became a problematic task. Performing a complexity analysis over the method, gave it the lowest maintainability index possible. However today, it has ended well, with the refresh now taking under 2 seconds!