A gift order needs to go to Lyon, but the customer wants her invoice in Paris. The software knows only one address. Entering Lyon fixes the parcel and makes the invoice wrong. Entering Paris does the reverse.
The developer needs to change what the software can store and what its different processes read. If it already has both addresses and the fix is merely awaiting release approval, that work would accomplish nothing. The defect has already been fixed.
The constructed examples in this series distinguish these situations by following documents, hours and decisions. The final instalment starts from real discoveries of forgotten access. I use “debt” beyond code to group these persistent costs without assuming they share a cause.
1. Two form fields, but one address on the invoice
In the fictional shop, adding a billing field makes it possible to save Paris alongside Lyon. But the invoice program still reads the original address. The document continues to say Lyon.
That program needs changing, followed by the accounting export that uses the same value. Old orders created with a single address must still produce their documents. The change is complete when the parcel, invoice and export each give the expected result, including for those orders.
When a simple field becomes a major change follows the successive errors and the four cases used to check the work.
2. Three hours of fixing, ten hours of refunds
Another constructed case: shipping is charged twice. Fixing the code takes two hours and checking it takes one. The fix is ready at noon on Tuesday but waits until the following Monday for release.
With fifty affected orders each day and two minutes per refund, those six days add ten hours of support work. Halving development time changes neither the release slot nor the refunds.
A fix finished on Tuesday, released the following week follows the timeline and approvals imposing that wait.
3. Automation waits while a duplicate explains the disagreement
A fictional sales report takes an hour to prepare every Friday. An automation proposal waits four weeks without a decision. Four hours of preparation and two hours of discussion have been spent without producing a trial.
The objection to automation is nevertheless verifiable: a deal appears twice in the export. Adding the rows gives €3,200, while counting each deal once gives €2,000. That defect defines the trial’s test. A parallel file can be compared with the manual report without replacing it.
When every initiative needs permission distinguishes permission to run that trial from the decision to retire the manual process.
4. The site responds while two invoices remain unsent
In the fictional batch used in the tooling article, 120 paid orders have produced 120 invoices. The sending provider accepted 118 messages, then rejected the next two. The availability check continues to open the homepage successfully.
Comparing expected invoice identifiers with those of accepted sends locates the two missing documents. Sending a new test email after the repair does not process them. Those two invoices need recovery, with their results tracked separately.
The website responds, but the invoices never arrive follows the batch through recovery and specifies the limits of each check.
5. The service is abandoned, but its code stays on the site
I removed an unused Brevo integration from a corporate website. Its code was still present. Abandoning the tool had not removed its technical integration.
I also found an expired domain on a list of permitted sources. The name was offered for sale at 50 dollars when I looked it up. That permission proved neither that a script was loaded from it nor that an attack had occurred. It required examination of trust granted to a name that could change hands.
The access that outlives the tools separates field observations from the checks needed on scripts, domains and permissions.
The fix depends on what remains to be done
These cases have different completion conditions. For the addresses, the invoice and parcel must show two distinct destinations. For the blocked fix, approval must lead to a release. For unsent invoices, every waiting document must have been retried or remain explicitly outstanding.
More development budget does not supply missing approval. Another availability check does not verify invoice sending. The name given to the debt matters less than the error or wait that the intervention needs to remove.
At Gridky, several changes came together in Drynuary: pausing new requests, fixing bugs and requiring tests for changed code. The team was subsequently reunited and my daily manual exception triage disappeared. Those observed changes provide the substance of that account.