Read on Twitter
There's a software opinion I often see expressed that seems right or hard to argue with:
"This code is over-architected"
"This code has too many layers"
It's unfortunate that the discussion often ends here, so I thought I would post a
on how to talk about it! 
"This code is over-architected"
"This code has too many layers"
It's unfortunate that the discussion often ends here, so I thought I would post a
on how to talk about it!
The root of these statements boils down to questioning the "abstraction".
Abstraction is a powerful concept in computer science but it is often highly subjective based on the preferences and experiences of the person who wrote them.
Here are some ways to frame this discussion..
Abstraction is a powerful concept in computer science but it is often highly subjective based on the preferences and experiences of the person who wrote them.
Here are some ways to frame this discussion..
We could use the concepts of Principles or Design Patterns to frame the conversation:
"This code violates the Single Responsibility Principle"
"This code mixes the Adapter and Facade Patterns"
This is helpful because it approximates pattern-matching for software developers...
"This code violates the Single Responsibility Principle"
"This code mixes the Adapter and Facade Patterns"
This is helpful because it approximates pattern-matching for software developers...
...humans are good at pattern-matching but frequently lousy at emotions and communicating, and I've often seen these concepts used as a mechanism to shut down conversation by people who put them on a pedestal...
We could use the concept of Conventions to frame the conversation:
"This code breaks from the conventions in the rest of the codebase"
This is helpful because it narrows the scope of the problem, but it can lead to debate on teams who haven't established strong conventions.
"This code breaks from the conventions in the rest of the codebase"
This is helpful because it narrows the scope of the problem, but it can lead to debate on teams who haven't established strong conventions.
I often see complaints around "over-architecting", "layers", and "complexity" stem from the same root cause:
The implementer did not take time to think about anyone except themselves.
This is an empathy issue more than a software design issue.
The implementer did not take time to think about anyone except themselves.
This is an empathy issue more than a software design issue.
So, what does "Empathetic Abstraction" look like? I think it involves considering:
"This makes sense to me, but I wonder if others will understand this?"
"This looks good, but I should consider how this impacts the systems' ability to change over time." ...
"This makes sense to me, but I wonder if others will understand this?"
"This looks good, but I should consider how this impacts the systems' ability to change over time." ...
... "I've built this entire mental model up by myself, I should get a second opinion to check my assumptions."
I don't want to disparage Patterns, Principles, or Conventions, but I think there is too much social pressure placed on "software developers" to understand and be able to communicate about these "technical" things; this leads to cold, thoughtless, and overly complicated systems.
So, what's the path forward for a software developer who wants to discuss these things in greater nuance?
Learn about Patterns, Principles, and Conventions, but also lean into Empathy as a core value that you filter your decisions through!
Learn about Patterns, Principles, and Conventions, but also lean into Empathy as a core value that you filter your decisions through!
