Anything that is “premature” is per definition incorrect. So there is no information in that sentence.
Having said that, a lack of architectural abstractions leads to badly designed code with a WTF count reaching the heavens. Have you ever seen UI code directly relying on a specific flavour of SQL implementation and database? That’s an example of how a lack of architectural abstractions leads to spaghetti code. Or how about the domain logic directly relying on a specific UI framework? Another example where an early architectural abstractions would have saved years of maintenance work. Again something I see all the time in the wild.
Leaky abstractions are bad abstractions. So what you are basically saying is “don’t implement bad abstractions”. Ehhhh right. I think we can all agree to not implement bad things. There is no insight or enlightenment there IMHO.
As I was writing my comment I was picturing this answer, and Socrates strategy for discussion, making others define and define ad infinitum. Fair enough. Quoting you:
> Having said that, a lack of architectural abstractions leads to badly designed code with a WTF count reaching the heavens.
> a lack of architectural abstractions leads to spaghetti code.
> domain logic directly relying on a specific UI framework?
If we are pedantic: lack of architectural abstractions, spaghetti code, and domain logic tied to an UI can also be interpreted as simply bad, so no information in either of our posts :)
Of course, I am joking. Saying that I think leaky abstractions are bad, or you saying that no abstractions are bad is new information (it reduces uncertainty). It tells us that we think that x is bad.
We can agree that bad abstractions are bad. In this thread, abstracting to early, or having leaky abstractions or not having any abstractions are just 3 positions on the topic of what a bad abstraction is.
I bet we could much easier agree with a specific example. In my experience all "big principle" discussions improve when we focus on a specific example. Otherwise people are thinking of different scenarios.
In any case, I can think of scenarios where each of those 3 positions is right, so I do not really disagree with any of them.
An example where a lack of abstractions is always bad IMHO is when the UI is directly depending on a specific database implementation. For example, dialog callbacks directly using the Oracle dialect of SQL to do business logic. I see that all the time in the wild and it makes the code super hard to improve, test, and maintain.
Another example is the domain logic directly depending on an external framework or database. A simple abstraction that reverts the dependency would make the code so much more maintainable and flexible.
Those examples are but two of the many I see in the wild all the time. Which makes me believe that often, in practice, the lack of architectural abstractions is a big problem.
The devastation of realizing that the days you spent working out the perfect class hierarchy or other complex design to handle every case was a complete waste of time and what you made is an over complicated mess that no one else can understand or use, and you could have just copied a method from one place to another and added a couple of ifs or arguments
Buisness world startup equivalent would be know your market audience.
Start out to broad and wind up wasting resources that could be put to better use.
Start out to narrow focus without knowing where need/$$ to keep going is and wind up wasting resources. Idealy, the narrower focus permits getting to the 'wasting resources' point faster.
Hiding the details via abstraction when details are still in development/need to be viewable & readily available defeats the purpose of abstraction making things simpiler/easier.
Anything that is “premature” is per definition incorrect. So there is no information in that sentence.
Having said that, a lack of architectural abstractions leads to badly designed code with a WTF count reaching the heavens. Have you ever seen UI code directly relying on a specific flavour of SQL implementation and database? That’s an example of how a lack of architectural abstractions leads to spaghetti code. Or how about the domain logic directly relying on a specific UI framework? Another example where an early architectural abstractions would have saved years of maintenance work. Again something I see all the time in the wild.