Avoiding Premature Software Abstractions

This left me with mixed feelings. On one hand, I see great value in single responsibility abstractions - they can improve readability (when looking at a single class that leverages them), and they can make components easier to test. On the other hand, I’ve coached a number of teammates over the years on SOLID principles and have continuously been met with push back or inappropriate abstractions (in my opinion).

A big lesson learned for me has been that there are multiple ways to do something - not everyone will have the same mental model as me. Going further, the more granular your mental model (I.e the more abstractions), the higher the chance that other teammates’ mental models will differ.

I still like abstractions for testability reasons - perhaps this is the right smell to check for when determining whether to split something up.

I agree with most of these practices. In a lot of the documentation about these things the warnings not to apply them prematurely exist and one must always weigh pros and cons, etc. It is easy to fall into the pitfall of having found a hammer and seeing nails everywhere after wading through reams of cool architecture patterns.

But there is maybe a downside to the advised refactoring processes as well. In a way you exchange consistency, predictable and repeated code structures, for less structural complexity but on an ad-hoc case-by-case basis because everywhere you make different choices to how far you take the abstraction.

This creates another way that a codebase can be hard to comprehend to newcomers or when returning to it much later. "Why do they use this pattern here, but not over there?", "Why is this an interface and that not?", etc. Similar ways of doing things become less recognizable.

It is comparable to the discussion that applying SOLID generally leads to more boilerplate, which requires discipline and results in more 'moving parts' to pay attention to, versus a much more practical approach that is less time-consuming in the short term. In this latter approach 'continual refactoring' is needed to avoid it starts to bite later on.

So I'd say: handle decision of 'prematurity' of abstractions with care too, before you remove them.

The Vertical Slice Architecture is a good approach. And a good folder structure and file naming convention can make tracing interfaces to the implementation that is invoked a lot easier as well.

PS. It might be cool to have those sticky note diagrams being more directly tied to the code with some tool, as a way to navigate and delve into it. And along with that suggest more elaborate alternative design chunks that can be 'swapped in' if refactoring to higher abstraction is warranted.

It can't be said too much that Abstractions are costly.

In the ideal case they're less costly than the alternative, but assuming a Pattern will magically make the code better can itself be even more expensive.

Finding the right balance between refactoring and not wanting to make the code harder to understand is always a challenge.

My general rule is: Don't abstract something before you have at least two different implementations that serve roughly the same purpose.