Thread by @refactorfiend

yea the bug shows up in the code, but many times the root cause of the bug is not the code, not even the design or the requirements, but the model i.e. your conceptualization of the domain

consider that you could be burning all that time on fixing that bug, when the root problem's not the bug, but a misunderstanding of the subject matter being coded to

the real bug could be in how you understand or how you look at the subject matter; could be a misaligned point of view or a missing concept that's unknown or not brought out explicitly in conversations with the subject matter experts and in turn, overlooked by devs

have you ever ?
- tolerated/created "non-domain-named" vars, methods, classes
- not asked that clarifying question in the design review; or overlooked that awkward desc in the spec
- hear one thing from the SME, see a different thing in the code and shrugged it off

it's me. i have 👋🏾

but all those things are opportunities for refactoring your understanding of the subject matter which in turn brings clearer direction for code refactorings.

and ideally less bugs. less tech debt. less maintenance costs

the misunderstanding is the bug; unclear understanding of the subject matter or one that is misaligned with that of subject matter experts is the bug

approach conversing with smes to resolve misunderstood concepts and their relationships, as you would approach pair programming to refactor some code

grab two like-minded devs, a sme, some coffee and a room; and get to brainstorming; dont work too many "model smells" at a time; give your minds time and space to process new info; always speaking in the ubiquitous language

#ooDesign #ddDesign #knowledgeCrunching