Your developers have been debugging for hours because the person who'd solve it within minutes is on vacation. Everyone is sweating and troubleshooting but they can't figure out what's wrong.
The code is dirty and unmaintainable, and only the developer who wrote it understands the code, and the details of how the logic works. But that developer is out of office for the next 2 weeks, and the bug needs to be fixed right NOW.
The QA E2E tests only cover the main scenarios of the system, but not the complex business logic of that main module. This means even when the developers do find some solution, they don't know if they've introduced a regression bug in the business logic.
I've found this to be a common problem faced by teams. For complex modules, the solution that worked well was to introduce Hexagonal Architecture and Unit Tests.
By introducing Hexagonal Architecture, it guided the team to design more decoupled application architecture - decoupling the business logic from infrastructural concerns, which made the codebase easier to understand and maintain.
By writing unit tests against the Hexagon (Application Core), it helped the team have protection against regression bugs in business logic.
Want to apply TDD in practice?
You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project, and get my feedback and answers to your questions. Access TDD in Legacy Code.