How to Minimize Bugs in the Software Innovation Process

How to Minimize Bugs in the Software Innovation Process

Author: | Published: 18 Sep 2019

Use_ML_AI_in_your_innovation_Process_to_prevent_software_bugs

“Everybody’s got a plan ‘til they get punched in the mouth” said the polemical pugilist Mike Tyson. That describes how we feel in the Innovation Team when an error comes through from the support teams.

After recently finalizing our development roadmap and starting our first sprints for enhancements due in 2020 we certainly had a plan, but maintaining existing software means it can’t be cast in stone. Receiving a support ticket is always a double-edged sword where you are disappointed that a bug was found but intrigued that a mango sharpening factory in the Democratic Republic of Manufacturistan is using our product.

The Beginning of Computer Programming

Being in innovation, we need to experiment and move quickly. Of course, this makes us particularly susceptible to possible quality issues.

This brings to mind the story of Ada Lovelace, considered to be the first person to write a computer program. Not to diverge too far, but it’s such an interesting story I think it warrants the time.

Ada was the daughter of the infamous poet Lord Byron (a notorious womanizer and drinker). Her mother pushed her into a career in mathematics and science to insulate her from womanizing artsy types like her father.

It was in these circles that she was introduced to Charles Babbage and his proposed Analytical Engine. She was the first person to attempt to apply algorithms to this machine rather than using it simply for calculations. Her first algorithm attempted to produce Bernoulli Numbers (a sequence of rational numbers that appear regularly in number theory) using the engine, a problem that at the time would have to have been calculated manually for each number. She never got to run the program because Babbage was never able to complete the building of the Analytical Engine due to inadequate funding, and Ada passed away only 10 years after this, but the program remains in her notes from the time.

Even the very first program had bugs

Recently, academics translated the program written from the original instructions into the modern language C in an attempt to finally run it. It’s here that we finally circle back to the theme of this blog post. When they ran the program, it was found to have a bug. So it’s comforting to me at least to know that even the very first program had a bug. After all, is it not human to err?

Bugs happen, but in innovation, we are approaching this problem from every angle possible in an attempt to prevent as many as possible but also make sure that when they do happen the fallout for our customers is as small as possible. Apart from the usual approaches of using agile and incremental development, unit testing and automated testing.

There are some other unexpected options we are investigating to help with this:

  • AI. The creation of software is in many ways similar to a conventional physical manufacturing process so why not use SYSPRO machine learning built just for this to help? If you can predict where problems will manifest, you can add additional quality checks at these points. As part of this, we could even predict the risk of changes to certain parts of the product and then add steps such as peer review or additional oversight for anything over a certain level of risk.
  • Provide other means of support. I’m a huge fan of the SYSPRO forum purely because it is available to everyone and allows direct debate. Providing a transparent forum for SYSPRO discussion not only allows for direct access to us in development but also a record of how previous problems were solved for all users to consult in the future.
  • Our theme for the next release is to make sure documentation is available and in-depth for all of the new features we have recently introduced. Customers and our channel partners need to be empowered and educated about all of our products so that when issues occur, they are equipped to handle most of them.
  • Meaningful errors! This is something that can be difficult to do in practice, but our errors should be meaningful to the users. They should not say what went wrong but rather what the user should do about the issue. Again, we’re doing our best to add this to the user experience of new features released by innovation.

Of course, all of this is part of a journey for us here, but I’d love to hear any other ideas on how to mitigate these issues.


Share this post

Leave your comment

Your email address will not be published. Required fields are marked *


Contact Us

How can we help you?