Stroustrup is decisively with me on premature abstraction:
Bjarne Stroustrup: ... I think I have a tendency to build the specific case first if I haven't tried something several times before, because it is pretty fundamental that we understand the concrete solution better than the abstract. When I see the same problem again and I get half way into the solution, I say, "Wait a minute, I'm doing the same thing twice." I did it once. I sort of understand it. I know what I mistakes I made in the previous solution. Now is the time to step back and see if I can have a general solution. That approach contrasts with the approach taken by people who start generalizing before they've tried it once—they sit trying to design a general solution to a problem that they have no experience with.
Bill Venners: That sounds like premature generalization.
Bjarne Stroustrup: Yes, that's right. You can have premature generalization as well as premature optimization.
(emphasis mine). Ray Davis of UC Berkeley makes similar points (last emphasis mine):
Lazy optimization is already a familiar idea: Don't waste time trying to guess at how to make lower-level code more efficient. Think about it during the high-level design and then gather evidence to show where performance and scalability need work.
Lazy generalization doesn't get talked about as much. But just as good programmers have an urge to make code clean and efficient, they also have an urge to generalize and make code re-usable. Much of the time they do that prematurely, get attached to their beautiful premature generalization, and the project drags. Instead, we try to wait for evidence that it's needed – usually the first copy-and-paste.
Incidentally, which name do you like better... "premature generalization" or "premature abstraction"?
Feel free to post a comment below. Please see my comment policy.
Formatting Rules (No HTML):