Comment by callmeed | Hacker News Reader

Comment by callmeed | Hacker News Reader

It's funny, I was reading old Joel on Software posts the other night and stumbled across this one: http://www.joelonsoftware.com/items/2008/05/01.html

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.

Yeah, I think Joel was right and wrong.

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))).

I think the main problem with the architecture astronauts is that they are trying to nuke a cockroach.

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.

Yes. Solving the generic problem is usually much harder than an actual problem. Only try to solve the generic problem if you really think that there are huge benefits of it, and really know what you do, and you can take huge risks. (Like creating MS Excel instead of creating a special accounting software.)

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))

Have you looked at QlikView? Sounds similar.

Thanks, I did not know about it. I think this is a still quite undiscovered territory so there is place for multiple companies/products here. (I will follow them to learn from them.)

Also, check out Hypernumbers. They've got an interesting take on the whole web spreadsheet thing.

Do you mind saying what your product is?

Thanks. I did not launch yet. I've written 10.000 lines of code already, but even cutting features heavily I can come out with an MVP only at about 18.000-20.000 lines of code approximately. I try to get good ideas from these kind of applications, but my product's maybe unique strengths are:

- 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.)

Did you try GoodData or PowerPivot ?

Wow, thanks, lots of stuff to read about tonight. :)

"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.

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.

I don't think dropbox really syncs (i.e. merges documents). It just stores versions, right?

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.

What do you mean? Dropbox syncs files amongst the computers you own and that is the most used feature I think. It is a sync. (In fact before using Dropbox I was using rsync over ssh.)

Alice has a file. Bob has a copy. They both edit it, and want the edits to be synchronized (by some sort of smart merge). That's the over-engineered syncing solutions Joel is talking about. Not just rsync.

Sorry about the semantics ... I should have been clearer.

It syncs, but punts on conflict resolution.

Which is correct behavior, trying to implement generic file synchronization is doomed to fail.

Yes, but that doesn't stop people trying.

It was one of those problems that everyone was solving in their own way. Either through shared folders, shared gmail accounts, mailing attachments, passing around USB sticks, or putting everything into a version control system.

There was no single solution that was both convenient, compatible across devices and platforms, and useful for all the usecases. Dropbox nailed that.

our school teacher has a mail.ru account the password for which is known by all the parents. if we're ill, we go there and see the homework :) anyone may change the password eventually as many people are not that internet savvy, i am always afraid of it

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...

I think it is one of those problems that most people don't run into until they do - for example, you're suddenly having to work from 2 locations on the same code base - then try to find some means of keeping both in sync... The first attempts I had at it ended up pretty much as a "too hard, not worth the effort" solution. I guess the pain threshold was not quite high enough for enough people, but now with a brilliant solution, a lot of people will revisit it, and with the multiplying numbers of web devices, it will become more of an issue - so it was more of an issue of tackling the problem at the right time.

Reply on news.ycombinator.com