The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Patter

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. The trouble with design patterns is that they're at the wrong level of abstraction. They're fine-grained enough to be described in a few pages and meaty enough to make the reader feel they've really learned something. But they're too coarse-grained and rigid to work the promised way, which is as primitives for software problem-solving. Treating these technical blobs as primitives leads to no end of trouble. People naively inline them into their programs because they have been told this is how it is done -- the OP says they are "proven solutions" (to what?) that can be "easily re-used" (how? ever notice they never show you that?) -- and the effect is like releasing a foreign species into an ecosystem. You end up doing the worst thing you can do to code, which is take it further away from the problem it is trying to solve. The gap between abstraction that precisely fits the problem and abstraction that sort of fits the problem is massive: it is the whole game. Out of that gap, complexity grows exponentially. Patternistas say, "But they're not supposed to be inlined naively. They're supposed to be adapted to the problem." But if you're already good at that, you don't need patterns. The point of patterns is to be a body of knowledge about how to make programs. If that's true, patterns should make naive programmers better. If their effect is to make naive programs worse, then they aren't really a body of knowledge at all. Mathematics, like software, is filled with recurring patterns and tricks that pop up in diverse contexts. Why doesn't math have "design patterns"? Because math culture understands that the only way to get good at math is to read theorems and solve problems. If a trick you've seen before is useful, use it; if not, drop it. The focus is always on the problem. Over time, you notice patterns, sure. But "patterns" are not the basis of teaching math, classical results are. I believe that software is like math this way. But the mathematicians have a luxury we do not: they don't need to grow their community by orders of magnitude in order to satisfy industrial demand. If you like math and have aptitude for it, the door is open; if not, see ya. Software, on the other hand, requires a massive work force, which raises the question of how to train it. Design patterns are a failed attempt to address that problem, which may not be solvable. Unfortunately, they confuse and delay the development of some good programmers in the process.