Logic Fault

Have you considered running your software on a computer?

On Maintainers

 Jan 22, 2023    2 min read

Code is read more than it is written.

Code is read by low context people in high urgency situations more than it is read by anyone else.

If your design patterns impose multiple “hops” in the call stack chain to a given business operation A invoked from another place B, a user who wants to modify/add to the set of side effects of A is more likely to make the change in the wrong place (e.g. in B, or in an intermediate/abstract-lookup-point location, rather than in or near A itself).

No matter what patterns/framework you apply, the average change request that touches code using those patterns will not be reviewed by someone who understands or cares about the patterns. This is not a failing (of your patterns or of your code review culture); over enough time, this becomes the average case everywhere.

Corollary of the two above: design patterns that move operations “away” from the place where they are requested both:

  1. Make code harder to read, and
  2. Increase the likelihood that code will become more confusing over time as maintainers make design-pattern-induced mistakes.

Inverse corollary: stack depth and MRO lookup breadth+depth are inversely proportional to code readability over time. Even if the depth is due to the application of a design pattern whose goal is to increase readability. Especially then, in fact.