This is definitely a pattern that I see. What's often overlooked after giving the problem and all subproblems much thought, every problem detail has a correspon

This is definitely a pattern that I see. What's often overlooked after giving the problem and all subproblems much thought, every problem detail has a corresponding implementation. A simple solution is one that can somehow group problem details conceptually then design a de/composition with natural seams and loose coupling. The difference in process I usually see is incrementally coding up a solution adding detail cases vs first mapping problem facets to concepts then factoring those concepts so the implementation has boundaries that follow the problem seams. Just because you can point to an aspect of the problem for every line of code that exists doesn't mean it's not over complicated. "Over complicated" is either an assessment by someone who doesn't fully understand the problem OR an inability to see or even imagine that a simpler solution could exist. Simple doesn't mean easy (e.g. add an 'if' somewhere in current design). Understanding is not only about coverage. A thing that I recently encountered is decomposing a problem top-down, and implementing the solution top-down, which lower-levels getting parts of the problem at hand unnecessarily leaking into it. Once I suggested to think of decomposing the problem top-down, but built the solution bottom-up from that envisioning, all the while trying to name concepts of the lower-level things and keeping them as free of unnecessary details at each level, things cleaner separation of concerns with deliberate interface points.