3 Reasons to move away from Excel Development

A spreadsheet is the tool of choice for a business starting up and requiring a quick and flexible low-cost solution to meet a business requirement, however as a business becomes more mature its requirements are likely to change over time and the same advantages can become disadvantages. Below I give you the 3 main reasons to move away from excel spreadsheets, but in my conclusion I also give you a couple of key factors to consider before doing so, because in some instances Excel is still the best tool for the job.

Maintenance is a Mission

Excel macros and VBA code is often initially created by non-developers, usually intelligent and knowledgeable people, but not trained software developers which normally results in something being created that is not only difficult to change, but if it should break, extremely difficult (see expensive) to fix. Whomever coded it initially is most likely the only person who truly knows how it works and every subsequent change will serve to further complicate matters, especially if the changes are undertaken by different individuals every time.

Cheap today, expensive tomorrow

While you don't have software license fees, servers or cloud platforms to pay for you still need to factor in the maintenance costs of supporting the spreadsheet and the more code/macro heavy it is, the more expensive it is. The more ongoing changes that are required, the more expensive it gets. Who is making these changes? If it's not a member of your team then where can you get access to Excel developers for short periods of time on a short notice period and at a reasonable price? To make it viable for software companies, they have to charge accordingly, if they are willing to take it on at all. I have been contacted countless times by businesses urgently needing an Excel developer to fix a business critical spreadsheet. Factor in the new versions of Excel and how that can affect a macro/code heavy spreadsheet and the costs mount up quicker than you can say "here is my letter to Santa".

Security? Not so much

Data within these spreadsheets is often of a sensitive nature, but controlling security and access to this data is challenging. I have heard of many instances where former employees have emailed themselves spreadsheets with financial data or customer lists. This lack of security also impacts data integrity, who has made changes and to what? I have seen further instances of portfolio managers making investment decisions based upon incorrect data because another user made a change to a formula in a cell.

 

Conclusion

There are many scenarios where an Excel-based application is the ideal solution, it can add a great amount of flexibility, allowing a business to get something up and running in a very short period of time and usually for a low initial cost. The points above do illustrate that there are some situations where the cons will outweigh the pros and then it might be time to consider a move away to a more structured product. The great thing about making that move is that Excel is a fabulous prototyping tool allowing the gathering of all the essential business requirements by key users. So not all bad news!

George Toursoulopoulos is a technology specialist and Director at Synetec, one of the UK’s leading providers of bespoke software solutions.

Managing Software Quality

We all aim to build software with zero defects, but that can prove to be expensive, time consuming and next to impossible if the correct processes, checks and balances are not in place. This short article is to identify the key points in the process to focus on in order to help ensure that defects are manageable.

What Requirements?

They key points in this area is how they are gathered, documented, agreed and just as importantly communicated to the development team. This has a large impact on what the perceived quality of the software and whether it in fact 'delivers', but this has to be balanced with the required timelines. A typical example would be use cases, these for most software builds are essential. Use cases document what the users need from the system and how they will use the system, this in turn educates the developers (which mostly do not have direct contact with the sometimes high profile end users) and QA and in turn increases the changes of delivering software that is fit for purpose. Using a system to manage requirements (documenting, sharing, signing-off, etc..) for larger builds is also recommended, there are many off-the-shelf systems that cater for this. Find the time or risk these end users becoming irate when their requirements are not met.

Speed or Quality?

The amount of time pressure impacts the build quality...fact! Trying to get key features delivered might be more important to the business than how robust the system is in the short-term. That priority also might change over time and what is important is that the stakeholders are deciding what the focus should be on. Some type of systems have no room for defects and in those scenarios having the business putting severe time pressure on their development team will not produce the results they are after. The management of the development team need to be in regular open communication with the stakeholders in order to be singing off the same hymn sheet. This will in turn impact the choices of project methodology (Agile or Waterfall), the testing process and the list goes on and on.

Testing 1,2,3

QA needs to be tailored to the project, but the underlying theme is that if the developers and QA do not have accurate information on how the system features will be used, regardless of how much time and effort is spent, they will still most likely not deliver a polished system. Other key issues for me are environment and ensuring that the development and test environment mirror, as much as possible, the production environment. The final critical element of testing is the structure. The process of producing, consuming and scope of test plans, test cases and test reports should be agreed so that the process of testing is as efficient as possible, saving time and money that can be used in improving the quality of the product.

Measure

The final point that I want to make within the context of this article is to measure the defects within alpha and beta testing and also UAT. This allows a more objective and less emotional view to be taken on the actual quality of the software. Stats that I like seeing are release work items, issues reported and most importantly categories of any reported issues e.g. requirements related, environment related and delivery related. Keeping these stats over a few releases greatly improve the ability to manage the development life cycle. Interestingly we see the greatest impact on the stats to be lack of use case scenarios and this is true across project methodologies.

George Toursoulopoulos is a technology specialist and Director at Synetec, one of the UK’s leading providers of bespoke software solutions.