Abstraction is possibly an art and few in the IT industry are good at it. Poor attempts at abstraction underly the common anectodal experience of 'failure' to consolidate software in context of business.
In my experience, the abstractions that are helpful are the ones that significantly reduce complexity in the code using them by hiding details that we rarely need to see. Put another way, they separate interface from implementation and the resulting interface is significantly simpler. That lets us reason about our code at a higher level without getting bogged down in unnecessary details.
Most of the problematic abstractions I see in the real world don’t hide much complexity but still introduce extra complexity of their own (with the latter even becoming greater than the former in the worst cases) or often leak so we still have to drill down through the abstraction to understand what’s happening anyway. Arguably, these are just two sides of the same fundamental flaw.
A lot of the most annoying and time-consuming abstractions at my company are, ironically, geared towards maintainability/extendability concerns.
We have wrappers around generic web service callers that rely on factories that create classes that convert between web service objects and domain objects, all wired together using interfaces for each service class and an IoC container, with its own XML configuration file.
The irony is that if the web service were to change its interface, you'd have to change like 10 files instead of like.. a single conversion function somewhere. And to begin with you had to create those 10 files in the first place. It's absolute fucking madness.
That looks like a great (that is, horrifying) example of the problem where the extra complexity introduced by the abstractions is actually greater than any complexity they successfully hide.
It’s frightening how often this happens at all scales, from little utility functions with names that are several times as long as their implementations right up to the kind of enterprise architecture that nightmares are made of.
I think you're not far off, and using art as a metaphor, you don't need to paint your house in shapes and colors that follow the golden rule, or write your to-do list in iambic pentameter. You can of course, and it might give you tremendous personal satisfaction, but it doesn't help the output be better.
I don't consider good abstraction a mere matter of aesthetics. But the economic realities of this field support your analogy regardless of that clarification.
Maybe in some cases the high cost of hiring artists capable of abstracting code to several platforms effectively is higher than the cost of writing and maintaining one codebase per platform. See iOS vs Android.
At the end of the day software is there to support the business, so if that is the more cost effective approach, why not? I've even argued for disposable software to a few clients.
However, I bristle a bit at a blog that misdiagnoses the problem as "over engineering". The problem is bad engineering, not over engineering.
Abstraction is possibly an art and few in the IT industry are good at it. Poor attempts at abstraction underly the common anectodal experience of 'failure' to consolidate software in context of business.