6.2Recurring issues (playbook)
The essentials in 30 seconds
- Name it: an incident is handled better with a precise symptom (“the control stays empty”) than with an impression (“it doesn't work”).
- Find the cause: link, query, permissions, dependencies, transaction — the same annoyance can come from several layers.
- Fix at the root: the targeted action prevents the symptom from coming back next week in another form.
Yacine's thread — the incident log
Yacine keeps an incident log for the trading application. Each entry notes the symptom seen by the user, the probable cause and the action that fixed the problem. Over the months, the same families recur: badly linked controls, overly broad queries, poorly applied permissions, dependencies forgotten at deployment and risky updates.
Reflex: name the symptom, check the cause, apply the targeted action — and spot the missing fundamental behind a recurring symptom.
One incident, one symptom
The first mistake is to fix things at random. You start by reproducing the incident and describing it precisely: which screen, which control, which user, which data. A clear symptom already halves diagnosis time.
From symptom to cause
The same annoyance can come from control linking, a badly filtered query, a misconfigured permission or a missing dependency. You work back up the layers one by one: data, code, interface, environment.
Fixing without going backwards
A lasting fix comes with a non-regression test and, if needed, a note in the log. Fixing a symptom without the cause guarantees it will come back in another form.
| Symptom | Likely causes | Actions |
|---|---|---|
| A control does not display the expected item's value | incorrect control/item link or unassigned control | check the link in the window and the traversal; check HAjoute, HModifie and HEnDehors (N1.4) |
| The application crashes on startup at the customer's site | missing dependencies (dll, framework, drivers) | deliver with the complete installer, check the prerequisites and test on a clean machine (N4.4) |
| A query becomes very slow in production | filter done in WLangage instead of the database, non-indexed items | filter in SQL (WHERE), index the filtered and joined items, bound the query (N2.2) |
| Two users overwrite each other's data | shared Classic database or no transaction | switch to Client/Server, wrap writes in transactions and handle conflicts (N4.1) |
| The automatic update loses or overwrites data | untested structure conversion, no backup | back up, test the conversion on a representative copy and plan a rollback (N4.4) |
| A user permission is not applied | misconfigured group, check only on the screen side | define groups by role, check on the server side and the interface side, test with real profiles (N4.2) |
Ready-to-say script — qualifying an incident (30 s)
“Can you tell me on which screen, which control and which user the problem appears, and with which data? I reproduce it, check the cause and fix it at the root.”
Keep this to frame an incident with a hurried user.
Ready-to-say script — announcing a fix (30 s)
“I've identified the cause: [link / query / permission / dependency]. I'm fixing it, retesting the full path and delivering the version with a prior backup.”
Useful for reassuring without promising blindly.
Copy-paste template — incident sheet
Symptom: [screen / control / message]
User: [profile] Data: [affected set]
Reproduced: yes/no
Layer: data / code / interface / environment
Probable cause: [...]
Action applied: [...]
Non-regression test: yes/no
Version delivered: [x.y]Copy-paste template — bounded and indexed query
// Filter on the database side, bound the result
MaRequete is a req
MaRequete = SQLExec("SELECT * FROM Commandes WHERE DateCmd = {ParamDate} LIMIT 100")
// Check the index on DateCmd in the analysis
// Do not fetch the whole file then sort in WLangageVery small business / small budget
Keep a simple incident log (date, symptom, cause, action): the team's memory is better than a heavy tool that is never filled in.
SME in Oran
Adapt to local realities: old workstations, unstable connections, quick interventions at the counter and explanations in simple French.
Remote / multi-site
Centralise the logs and document each fix so that the remote colleague understands without calling the user back.
Cross-cultural
Describe the symptom without business jargon before transposing: a clear message is better than a misunderstood error number.
48h challenge — apply it tomorrow
Take a real incident and apply the sheet: symptom described, layer located, cause checked, action applied and non-regression test.
- I can qualify a symptom, locate the layer and apply a targeted fix.
- I have a reusable incident sheet and a non-regression reflex.
- I have done the 48h challenge or scheduled its date.
A query in the application becomes very slow in production. What is the first action?
Reflex: name the symptom, check the cause, apply the targeted action — and spot the missing fundamental behind a recurring symptom.