This is a constant in software development. Planning to avoid this, as best as possible, is one of the most important functions of Information Architecture. With that, however, we will never know 100% what will work, and what springs will shoot out everywhere until we have an application in the wild, on production environment, with actual people performing operations at scale.
One of the frameworks we use to evaluate an applications stability is known as technical debt. Dave Farley (@davefarley77) does an excellent breakdown of the concept below:
Knowing that we will, to some degree, have to encounter technical debt on an initiative is important to plan for. Knowing how to produce a fix for an issue that's encountered is a slightly different set of skils.
By 2022-2023 I am sure we have all seen somebody who's day has been ruined by technology. When things don't work as expected, it is annoying. In saying that, fixing this requires a form of due diligence that breaks down the problem into ways that can be tracked, tested, and shipped.
Understanding the ability to complain about software deficiencies is fundamentally opposed to the ability to break down bugs and communicate them is an important first step.
This post is setup to explain an integration problem I experienced by two pieces of software that support Acorn's Operations. Quickbooks Online and Scotiabank.
Knowing both outfits, like ourselves, are customer service providers it's important that we frame these reports constructively. So, let's begin:
As a visitor of Quickbooks Online I was trying to update my bank statement in the accounting software from my bank account housed at Scotiabank.
Generally, there is a 2FA safeguard that runs from Scotiabank which authorizes the request from Quickbooks to fetch the data from Scotiabank.
The first step, then, is to outline what the desired outcome of the application user is. From there, it's important that we distinguished between what we experienced and what we expected.
After trying to refresh the banking data from Scotiabank into Quickbooks, an alert was presented
The error message:
I was then brought into an interstitial screen, followed by a set of instructions.
And Eureka! I had thought that the process had completed, the journey was over.
Oh, how I was wrong...
What I experienced was the arrival of the dialogue box explaining that I would be getting a notification on my mobile device to authorize the Two Factor Authentication (2FA).
What I did not receive ... was the notification.
Fancying myself a "bit of an upper intermediate novice" at the QuickBooks Online, I was surprised to not have a robust push notification sent to my mobile device. In my past experiences using the platform, this had worked fairly seamlessly. I would
After several attempts at doing this, I was then issued a new warning saying there may be some complications on the banks end.
Considering that Scotiabank and Quickbooks are different organizations, with different teams, managing different customer service offerings it is hard, at a cursory glance, to know exactly what the problem is. Being able to write a straightforward report, with visual examples, can help these outfits isolate where the problem is coming from.
Conversely, I could spend half a day on hold, get emotional with a customer support representative, fail to articulate the nuances of the problem to the teams themselves, and let an issue that could very well be experienced by many to fester and live on unresolved.
On the more technical side
Providing steps and visual examples can really help technical teams isolate the source of the problem. Is the 2FA a security service employed by the bank experiencing versioning issues with their API? Or could a model adjustment from the bank fail to run the callback script for dispatching the push notification...
It's not worth it for me, the reporter, to get into this much detail of course. It is important for the technical teams to know where the issue is happening, be able to ask the right questions, draft technical tickets with code snippets and technical resources attached, and ultimately assemble the team to produce the fix.
And perhaps this song has much more to do with isolating the code based correlates of software bugs in the absence of dutiful reproduction strategies...
Writing test plans for feature implementations is a proactive strategy to ensure that our code, and application features, work as expected. Having an established process for triaging, and repairing deficiencies reported from an application is a slightly different tactic.
Combining the ability to forecast, and treat, bugs on an ongoing basis is how we can do our part to manage the inevitability of technical debt.
