So what you end up with is a framework that solves nothing that requires a bunch of configuration, or unnatural calls to its API(s) to get your one problem solved.
If your 1 problem took, say, 100 "units" of coding; often the framework will take 400 since it's generic. Then you have to code another 50-75 for your one problem.
Sure, the next guy also has only 50-75 to do, but too often these astronauts have no idea of the ROI of the 400, they just assume that "REUSE IS GOOD!" since that's all they've ever been taught. The ROI may never breakeven, much less get profitable.
Also, astronauts VERY often never have to dogfood what they've written, and have no idea if what they've done is actually any good, or usable.
"Before you design for reuse, make sure you've designed it for use." I'm convinced "reuse" has caused more unnecessary code than anyone imagines.
An example of something that solves lots of problems at once well: a language and its compiler/interpreter.
A framework makes a lot of sense for internal applications and large companies. You're often repeating a very similar application over and over (same style, same database, same replace-unwieldy-Excel/Access power user DB problem.)
A framework makes a lot of sense for consulting-ware. Deploying 20 versions of a highly customized application with a lot of reuse. As I see it, this is the use case for Spring. I can't think of another way to easily test such a system.
Frameworks make sense when you need to assemble a team together quickly to solve a problem. You are inheriting a set of best practices that allow a quicker norming phase. Frameworks make sense when you have average and junior programmers as the primary workhorses on a project. (Note: we don't have enough A-listers to solve all of the world's computing problems.)
Frameworks aren't for every problem. That doesn't make them useless.
I heard "high-level program translation framework".
If something actually is the template to a lot of problems then obviously it's going to be successful.
YES.
This idea has always bothered me: "don't solve a template of a lot of problems, solve one problem."
Isn't that the essence of innovation? To kill lots of birds with one stone?
The problem with "architecture astronauts" is that they over-think their problem, and they spend too much time over-thinking and over-developing before they really understand the problem space. It's a problem of over-engineering and isolation, not wanting to kill more than one bird.