Every software on the planet has bugs and small glitches here and there. These can be annoying or crippling depending on the severity of the bug and the process for fixing it. We’ve seen this far too often in the industry. For example, we worked with a software vendor once who published a relatively minor update to their software.
Despite internal quality assurance testing, a bug was released causing a major problem with a company’s inventory valuation if they were using a specific costing method and under specific circumstances (upgrading from one earlier version to the new release). This bug caused a lot of grief for our customers because inventory valuation is vital to financial reporting and once the bug was introduced – there was absolutely no easy way to fix the problem without a highly skilled software engineer working some magic in the back-end of the database.
We fixed a lot of issues for customers after this bug was introduced and while they were happy that we could fix it (most other consultants couldn’t) – it came at a cost upwards of $5,000 to $10,000 which most just accepted as the cost of doing business.
The fact is that bugs happen and they will continue to happen probably forever. Humans make mistakes and even computer-generated code can occasionally include a bug or two.
But sometimes glitches and bugs are more prevalent and can have much more severe consequences on your business. These are considerations you need to make when evaluating new business applications and weighing the pros and cons of switching off your current software.
Most of the older more established applications on the market are pretty solid. Unless the vendor is porting them to new technologies – they likely have few bugs. This may also be due in part to the lack of research and development made to the products as they are no longer strategic to the vendor. After all, the less code you change, the fewer bugs you’ll create.
On the other hand, newer business applications are more likely to have bugs since they haven’t been in the market as long and there are fewer customers using them or pushing the limits of the software capabilities. Further, fewer customers means that the applications may not be deployed on as many iterations or combinations of technology platforms which are often the source of bugs and glitches. Lastly, newer products are often in rapid R&D mode where the publishers are trying to put as much functionality in as fast as they can to catch up to more established competitors. In order to do this, they have no choice but to cut out some of their quality control and this inevitably will result in increased bugs.
So, what do you do? You may not be happy knowing your current system is about to ride off into the sunset but you also know that it’s a safe bet. It works and if it’s not broke – don’t fix it. But on the other hand, you know that you’re not going to be able to continue growing if you stay on the old software.
Our recommended approach for customers is to stay ahead of the technology curve. You should be fine being on newer technology so long as you’re not on the bleeding edge – the absolutely new technology that is riskier due to relatively low adoption.
Instead, we recommend that our customers select products that have been on the market for a few years and even then – we recommend that they are slower to adopt new releases – especially major releases that have a higher likelihood of having bugs. Let other users adopt the latest versions and let them suffer through the issues inherent with new releases. You can adopt them later on once the major issues have been resolved.
This is an especially good strategy for installed software where you have a lot more control over updates and upgrades to your system. A few years ago, one of our software vendors released a major upgrade to their software. It was pretty amazing – chock full of new features that everyone wanted. But the initial release was horribly buggy and everyone that was on it couldn’t get their hands on the patches and bug fixes fast enough. Customers were not happy. Some of our customers waited until our partner released the next release and they experienced considerably less pain having allowed others to do the hard work ahead of them.
You may not have this option with SaaS applications since updates are most often published and pushed out to customers on-demand automatically. Some cloud accounting and business applications allow you to deploy the software in a single-tenant or dedicated environment where you can decide when you want updates and upgrades to be applied. These tend to be a little more costly than multi-tenant or shared environments but they do provide some level of control and a bit more security that some companies prefer.
A study released by tricentis.com in 2016 indicated that software bugs, glitches, and other failures had an estimated economic impact of $1.1 trillion dollars on the US economy. The study went on to explain that the bugs affected more than 360 companies trickling down to more than 4.4 billion customers causing a loss of more than 315 years to fix the issues. Now that’s a big problem!
There is no doubt that bugs negatively effect your business every day. The challenge is to find the least buggy software available and to mitigate the risk of introducing bugs when you upgrade to new versions.
In general, it’s almost impossible to know if a product is buggy or if it will eventually be buggy. Your best bet is to talk to existing customers using the software and when in doubt – go with larger vendors and products that have been on the market for a longer period of time as they will likely be much more stable and safer overall bet for your organization.
If you’re existing system is riddled with bugs you can wait it out which could be very painful and costly or you can jump ship and find a replacement product. No one can tell you when to move. It’s a matter of preference and only you know how much you and your business can tolerate a buggy system.They key is to spend the time to understand what’s changed, or what’s going to change. Read more here.
