The Wrong Abstraction
sandimetz.com
The Wrong Abstraction
1–10 of 121 posts
Re: The Wrong Abstraction
#2I wrote about the problem here: http://250bpm.com/blog:36
The fact that abstractions can often add complexity rather than remove it should be taught in schools.
The problem with distinguishing between the two cases is that it often requires business domain knowledge. And programmers, sadly, rarely care about the domain logic.
Re: The Wrong Abstraction
#3Richard P. Gabriel wrote about this in connection with the idea of design patterns, e.g. in Patterns of Software. Here's a nice quote from the beginning of a chapter:
> "The room fills with cold, conditioned air; outside the heat hazes, filtered through greened glass windows: a new building hardly first populated. The speaker is wild-eyed, explaining new ideas like a Bible thumper. His hair is a flat-top; his mouth frowns in near grimace. He strides to my seat, looks down and says in a Texas drawl, 'and the key is simply this: Abstractions. New and better abstractions. With them we can solve all our programming problems.'"
Re: The Wrong Abstraction
#4This may be obvious, but when working on Java I've found that this applies not just to classes but also to methods. When refactoring a poorly-factored class, often the most effective way forward is to inline all the private methods (introducing a lot of duplication) and then factor out the duplication.
Re: The Wrong Abstraction
#5I wrote about the problem here: http://250bpm.com/blog:36 The fact that abstractions can often add complexity rather than remove it should be taught in schools. The problem with distinguishing between the two cases is that it often requires business domain knowledge. And programmers, sadly, rarely care about the domain logic.
> And programmers, sadly, rarely care about the domain logic.
Oh, but we do. It's the one thing we want to know but we pretty much never get from our customers. No surprises there - most people are not equipped to express their "domain logic" in a way that is useful for automating it; quite often they don't even understand it. Humans can hand-wave their way through anything, relying on intuition, patterns and methodologies. They don't need to understand what they're doing deep enough to express it as code.
And so what usually happens is that your client/manager gives you a nonsense spec saying "this thing should do that when clicked, and that thing should do something else". And, as a programmer, you then have to reverse-engineer the domain abstractions from it; abstractions the people giving you the spec probably don't understand themselves.
Re: The Wrong Abstraction
#6While I have no objection to the notion that duplication can be the right choice in some circumstances, and I completely agree with the author in thinking that pressing on rather than backtracking and taking a different path is a source of much complexity, his pseudo-example misses a third alternative: instead of (re)introducing duplication wherever the current abstraction is used, derive a generic abstraction covering the common aspects of the previous and new requirements, and use that in implementing two new abstractions, one to replace the old, and the other for the new cases.
Re: The Wrong Abstraction
#7If only Programmer B had avoided that initial choice to preserve the broken abstraction rather than abandoning it then and there.
He must have been practicing Deadline Driven Development.
Re: The Wrong Abstraction
#8This may be obvious, but when working on Java I've found that this applies not just to classes but also to methods. When refactoring a poorly-factored class, often the most effective way forward is to inline all the private methods (introducing a lot of duplication) and then factor out the duplication.
It is even more effective when you are faced with a bunch of classes, most of which do nothing but delegate their responsibilities to others. I have a case in front of me right now.
Data-flow analysis was a method that was swept away (somewhat unfairly) on the grounds of being too procedural and not OO. One of its key tenets was that once you had discovered the essential flows and interactions, you should discard the problem-space partitioning that helped you find the graph, and use the graph to partition the solution space (which might well result in the same partitioning, but not always.)
Re: The Wrong Abstraction
#9I wrote about the problem here: http://250bpm.com/blog:36 The fact that abstractions can often add complexity rather than remove it should be taught in schools. The problem with distinguishing between the two cases is that it often requires business domain knowledge. And programmers, sadly, rarely care about the domain logic.
> And programmers, sadly, rarely care about the domain logic. Oh, but we do. It's the one thing we want to know but we pretty much never get from our customers. No surprises there - most people are not equipped to express their "domain logic" in a way that is useful for automating it; quite often they don't even understand it. Humans can hand-wave their way through anything, relying on intuition, patterns and methodo…
What I meant is that looking at an average programmer's resume feels relly weird: A web shop. High-performance trading. Game development. Scientific computing. Telecom. And so on. No way anyone can be a domain expert it that many areas.
Also, you often hear folks saying things like "I am a Java programmer." Stuff like "I am a telco programmer" is much more rare.
Re: The Wrong Abstraction
#10I wrote about the problem here: http://250bpm.com/blog:36 The fact that abstractions can often add complexity rather than remove it should be taught in schools. The problem with distinguishing between the two cases is that it often requires business domain knowledge. And programmers, sadly, rarely care about the domain logic.
Being able to lead your customers to explain clearly what they really want (and, in some cases, to help them understand why they can't have/afford it) is one of the skills of a productive programmer. It involves a lot more than just listening, though that is a good starting point.