The Patterns We See Most
Last updated:
The five most common
- No error handling beyond the happy path
- No monitoring, so failures are silent
- Credentials in the repository
- No tests, so nobody dares change anything
- Query multiplication — one query per row in a loop
The second costs the most over time. A system that fails silently produces wrong data for weeks before anyone notices, and by then the downstream effects are considerable.
Five more
- Dependencies never updated, until they cannot be
- Configuration hard-coded, so environments differ
- Everything in one module, so nothing is testable
- Bare exception handling that swallows real errors
- No idempotency, so retries create duplicates
Bare exception handling deserves its own mention
Catching every exception and continuing hides the failures you most need to see. It turns a loud problem into a silent one, which is the wrong direction.
Catch what you expect and can handle. Let the rest surface, be logged and alert somebody.
The costs
| Mistake | Typical cost |
|---|---|
| No monitoring | Weeks of wrong data |
| No error handling | One bad record stops everything |
| Credentials committed | A security incident |
| No tests | Changes take three times as long |
| No idempotency | Duplicate records, hard to unpick |
They are all cheap to fix early
Every one of these takes hours to address during development and days or weeks to retrofit. None of them requires a rewrite.
If you have inherited a system with several of them, address monitoring and idempotency first — they prevent the most damage.
Frequently asked questions
Which should we fix first?
How do we know if we have these?
Can these be fixed incrementally?
What if the original developer is gone?
Recognise more than three of these?
Most inherited systems have them. Monitoring first — it tells you what else is wrong.
Related services
What we build for problems like this one