He was right because there are architecture-astronauts who overdesign things that they don't understand yet.
He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems. Solving a template to a lots of problems can be a huge business. Think of the personal computer. Think of MS Excel. Think of Oracle. It is just very hard to get these things right, because it is very hard to see the market for these generic products in advance. Also generic things are very technology heavy usually, so hard to convince investors. (Maybe I am just defending myself here, because I am also working on a generic application which is about helping businesspeople to access/maintain/query their data intuitively. (Like Excel just with a bit more constraints (with relational db. server backing))).
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.
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.
Have you looked at QlikView? Sounds similar.
Do you mind saying what your product is?
- helping agile 'database evolution' by providing schema refactoring, and automatic schema refactoring advice by detecting redundancies.
- automatically creating indexes using query statisitcs.
- presenting a data maintenance GUI based on the relational schema, which is very similar to modern CRUD applications directly developed with the given schema in mind. (for example intelligent automatic generation of form layouts)
- semi-natural query language support. (actually I've extended the SQL Select command's syntax with quite a lot of intuitive and comfortable constructs.)
In other words, they are trying to find an overly wide and generic solution while all they have is a specific instance of a problem in a particular implementation they need to design for.
Architecture astronauts tried to build generic diffs and merges, on top of rich documents. Think SVN for Word docs. Then they though about metadata, like bug-reports and other actions. Then you can host the bug report (and the project management system, and the wiki) on top of the synchronization architecture.
Dropbox, at its core, just keeps your files and 30 days of history.
Sorry about the semantics ... I should have been clearer.
There was no single solution that was both convenient, compatible across devices and platforms, and useful for all the usecases. Dropbox nailed that.
she should use dropbox, google docs or have a mailing list, but i don't know how to say that. she knows only web mail as it's around for decades...
From the essay:
"The hallmark of an architecture astronaut is that they don't solve an actual problem ... they solve something that appears to be the template of a lot of problems. Or at least, they try. Since 1988 many prominent architecture astronauts have been convinced that the biggest problem to solve is synchronization.
...
Jeez, we've had that forever. When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I'm sorry. It seems like it should be. But it's not."
I immediately thought of dropbox. It appears, to some degree, it is a problem and some people do care. Like Chris said, its the execution and people that made the difference.