Engineering discussions often start with a proposed practice: TDD, a new tool, a process change, or an architectural approach.
The risk is that the discussion becomes focused on whether the proposal should be accepted, while the original problem quietly disappears.
I saw this in a recent conversation about TDD. The team did not want to adopt it broadly, but that did not mean the underlying concern was invalid. The real issue was about confidence in changes, test quality, and how easily problems could escape into later stages.
Once we moved the discussion back to the problem, TDD became one possible option instead of the decision itself.
That distinction matters. A proposal can be rejected while the concern behind it still deserves attention.
A few questions help:
- What are we actually trying to improve?
- What evidence shows this is a problem?
- What smaller step could we try?
- Who owns the next step?
I wrote more about this here:
https://ammar-najjar.com/blog/separate-practice-from-problem/
Top comments (0)