4 ms·
Contrary view: Abstraction is possibly an art and few in the IT industry are good at it. Poor attempts at abstraction underly the common anectodal experience o
by eternalban 10y ago
Contrary view:
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.
- jjawssd 10y agoMaybe 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.
- otaviokz 10y agoI'm not sure your example applies perfectly to the question at hand. But as a native mobile dev I feel a deep affection for it :P
- eternalban 10y agoAt 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.
- ChuckMcM 10y agoI 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.
- eternalban 10y agoI don't consider good abstraction a mere matter of aesthetics. But the economic realities of this field support your analogy regardless of that clarification.
- onion2k 10y agoAbstraction is possibly an art and few in the IT industry are good at it. Sounds like a good reason to avoid it.
- Chris_Newton 10y agoIn 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.
- plaguuuuuu 10y agoA 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.
- Chris_Newton 10y agoThat 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.
- eternalban 10y ago> the abstractions that are helpful are the ones that significantly reduce complexity Accepted! (Did I mention anything about complexity?)