Bug Fixes? It's Still Broken

In this article, we explore the process of xTuple ERP (enterprise resource planning) internal bug tracking procedures to help answer questions regarding bug fixes and patches. xTuple has a specific, documented process for managing our bug list using CRM (customer relationship management) incidents for bugs, feature requests, support requests, and other internal work. Let's dive into the what and how of bug reports...

What's Happening?

It happened again last night — someone messaged me to say that our ERP application crashed even after we said the crash was fixed. What happened?

The Internet era has led us to expect instant gratification. It seems like every day there's another application to upgrade, a new version of the operating system to install (that happened to me last night, too), a new release to pilot. The world moves at such a rapid pace, but — break it down — and you'll see that this constant barrage of updates is really a bunch of infrequent changes by a large number of organizations.

xTuple's average for the desktop client over the past 8 years has been about one release every 2 months, not including alpha, beta and candidate releases. [NOTE: I count 52 releases between v3.5.1 in July, 2010, and 4.11.3 in March, 2018.]

There are two factors that contribute to the question asked, "What's Happening?"

• User expectations
• Bookkeeping

I'll start with Bookkeeping, because it's the easiest to explain. We have a specific, documented process [see GitHub wiki] for managing our bug list. The references to "dogfood" are to our own xTuple ERP database (remember, we use our CRM incidents for bugs, feature requests, support requests, and other internal work). A bug report typically goes through the following states:

• New — someone reported it
• Confirmed — someone else could make it happen
• Assigned — someone is going to fix it
• Fixed/Open — someone has proposed a fix
• Fixed/Resolved — the proposed fix has been accepted for a specific release
• Fixed/Closed — someone has tested the proposed-and-accepted fix and verified that the problem no longer occurs

At this point we are done internally with this issue. There's nothing left to do except document it in the release notes, which is a bulk data extraction done when we build the release.

It's these "fixed" states that collide with User Expectations. If the bug report says it's fixed, why isn't it fixed? Because you, the end-user, don't have that fix yet. I won't bore you with details nor whine about how hard it is to push fixes. I'll repeat what I've said before in Things That Keep Me Up At Night (TTKMU@N) — Bugs, Bug Reports and Pesky Misunderstandings: any change in your ERP software has the potential to disrupt your business.

At this point you have choices. You could wait for the next release, test with a nightly build (please, do NOT put this in production!) to reassure yourself (and us) that the bug fix is correct, work around the problem using the application as is, and/or patch it.

Many bugs can be temporarily patched on the fly — not all but many. Some combination of desktop client scripts, revised report definitions, MetaSQL statements, and stored procedure changes can be applied to your database to tide you over until a release that fixes the bug is published.

This is where a support contract, cloud hosting, professional services hours, or power-user training may come in handy. Developing a patch to work around a bug takes time, and installing a patch on your database takes some knowledge. We can't afford to write and distribute patches for every bug, and you don't want us reaching into your production database and forcing changes on you. If we have a conduit for communication, such as Tech Support, then we can decide together what to patch and what to leave for the next release.

So where does that leave us? Bugs get fixed.

The record keeping runs ahead of the end-user experience. It's like that old saw, "the check is in the mail." If we say it's fixed, check the "fixed-in" version to get some idea of how long you'll have to wait for it to arrive in your software. If you need it sooner, check the bug comments and document attachments to see if there's a "credit memo" with your name on it!