Hacker News Reader

Comment by api | Hacker News Reader

"He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems."

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.

View on HN

One issue with that is that solving a template of problems really doesn't solve anything specific.

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.

Frameworks are the wrong way to solve many problems at once. Frameworks are a disease.

An example of something that solves lots of problems at once well: a language and its compiler/interpreter.

Sometimes yes, sometimes no.

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.

> a language and its compiler/interpreter

I heard "high-level program translation framework".

Both of you (nadam and api) are arguing with a strawman, not what with Joel actually wrote: "they solve something that appears to be the template of a lot of problems"

If something actually is the template to a lot of problems then obviously it's going to be successful.

Reply on news.ycombinator.com