TL;DR: it depends on what you're trying to solve.
I've had a similar conversation with my Gramps about this, while we were talking about how Func and Action in C# are awesome. My Gramps is a very old timer programmer, that's been around source codes since software was run on computers that took a whole room.
He changed techs several times in his life. He wrote code in C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java and eventually started C# as a hobby. I learned how to program with him, sitting on his lap while I was but a devling, carving away my first lines of code on the blue editor of IBM's SideKick. By the time I was 20, I already had spent more time coding than playing outside.
Those are a bit of my memories, so excuse me if I'm not exactly practical while retelling them. I'm somewhat fond of those moments.
That's what he said to me:
"Should we go for the generalization of a problem, or solve it in the specific scope, do you ask? Well, that's a... question."
Gramps took a pause to think about it for a brief moment, while fixing the position of his glasses on his face. He was playing a match-3 game on his computer, while listening to a Deep Purple's LP on his old sound system.
"Well, that would depend on what problem you're trying to solve", he told me. "It is tempting to believe that a single, holy solution for all design choices exist, but there isn't one. Software Architecture is like cheese, you see."
"Doesn't matter what you think about your favorite, there will always be someone that thinks it is smelly".
I blinked in confusion for a moment, but before I could say anything Gramps went on.
"When you're building a car, how do you pick the material for a part?"
"I... I guess it depends on the costs involved and what the part should do, I suppose."
"It depends on the problem that part is trying to solve. You won't make a tire made of steel, or a windshield made of leather. You pick the material that best solves the problem you have at hand. Now, what is a generic solution? Or a specific one? To what problem, to what use case? Should you go with a full functional approach, to give maximum flexibility to a code that will be used only once? Should you write a very specialized, fragile code to a part of your system that will see lots and lots of uses, and possibly lots of changes? Design choices like those are like the materials you pick for a part in a car or the shape of the Lego brick you pick to build a little house. What Lego brick is the best one?"
The elderly programmer reached for a little Lego train model that he has on his table before continuing.
"You can only answer that if you know for what you need that brick. How the hell you'll know if the specific solution is better than the generic one, or vice versa, if you don't even know what problem you're trying to solve? You can't see past a choice that you don't understand."
"..Did you just quote The Matrix?"
"Nothing, go on."
"Well, suppose you're trying to build something to the National Invoice System. You know how that hellish API and its thirty thousand lines XML file look like from the inside. How would a 'generic' solution for creating that file would even look like? The file is full of optional parameters, full of cases that only very specific branches of business should use. For most cases, you can safely ignore them. You don't need to create a generic invoice system if the only thing you'll ever sell is shoes. Just create a system for selling shoes and make it be the best darned shoe-selling invoice system out there. Now, if you had to create a invoice system for any type of client, on a more broad application - to be resold as a independent, generic sales system, for example - now it is interesting to implement those options that are only used for Gas, food or alcohol. Now those are possible use cases. Before they were just some hypothetical Don't use cases, and you don't want to implement Don't use cases. Don't use is the little brother of Don't need."
Gramps put the lego train back on its place and turned back to his match-3 game.
"So, to be able to pick a generic or a specific solution for a given problem you first need to understand what the hell that problem is. Otherwise you're just guessing, and guessing is the job of managers, not programmers. As almost everything in IT, it depends."
So, there you have it. "It depends". That's probably the most powerful two-word expression when thinking about software design.