Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"How hard can it be to implement?"

answers.37signals.com

Post reply on HN
Print view View original

61–70 of 102 posts

Re: "How hard can it be to implement?"

#61

Post by Dylan16807 »

ellyagg wrote: post #58
jemfinch wrote: post #54

Earlier quoted context omitted.

Whatever the case, when I see a programmer doing a linear search through a linked list, I think you must agree that I'm justified in saying that I have no reason, based on that observation, to trust in that programmer's competence. In fact, I think it could easily be argued that in the absence of additional data, it would actually constitute a reason not to trust the programmer's competence. While I fully agree that…

> Whatever the case, when I see a programmer doing a linear search through a linked list, I think you must agree that I'm justified in saying that I have no reason, based on that observation, to trust in that programmer's competence. In fact, I think it could easily be argued that in the absence of additional data, it would actually constitute a reason not to trust the programmer's competence In Erlang, the most comm…

Only the ones that won't switch to a log-performance data structure when it's causing them trouble.

Re: "How hard can it be to implement?"

#62

Post by ams6110 »

thisisnotmyname wrote: post #2

Is there really no simpler way to solve this problem? "Moving a message needs to move all of the message's comments, and all of the comments' files, and all of the comments' files' versions." Why can't you just change some top level reference in the database? I'm imagining a Projects table and a TodoLists table. Each TodoList has something like a projectID foreign key right? Why can't you just change that and automat…

Maybe we're seeing a downside of the YAGNI, shoot from the hip, do the simplest thing design philosophy.

Re: "How hard can it be to implement?"

#63

Post by mkr-hn »

dasil003 wrote: post #45
latortuga wrote: post #38

Earlier quoted context omitted.

Are we really taking cheap shots about age now? This is not how an argument is won and not how we do things around here. Your point stands on its own without ageism.

Fair point, but this type of hubris is far more common (and more forgivable) in youth. Is it ageist to recognize this fact?

I've seen it at about the same rate in old and young. Though older people seem less likely to recognize and correct their error.

But that's from personal observation, and I haven't made a point of recording my findings for analysis. I suspect you haven't either.

Re: "How hard can it be to implement?"

#64

Post by dasil003 »

vog wrote: post #49
dasil003 wrote: post #45

Earlier quoted context omitted.

Fair point, but this type of hubris is far more common (and more forgivable) in youth. Is it ageist to recognize this fact?

It is irrelevant and very disturbing for the discussion. So it may not be exactly ageism, but it is definitely inappropriate.

You're right. That was a mistake on my part, I'll take it into consideration for the future.

Re: "How hard can it be to implement?"

#65

Post by dasil003 »

jemfinch wrote: post #55
dasil003 wrote: post #52

Earlier quoted context omitted.

Pick 10,000 random features and aspects of a software program to be implemented over a 10 year period. Some architectural choices will benefit some and harm others. There is no choice that will make "all easy problems easy". You can't just arrive with one specific feature pulled out of thin air 6 years later and claim that if it is not easy than the system architects were incompetent. Do you really not see that?

> You can't just arrive with one specific feature pulled out of thin air 6 years later and claim that if it is not easy than the system architects were incompetent. The problem is easy. Seriously, it really is. Most of the programmers here have probably done something almost exactly like it ten or more times in their relatively short careers; I know I have. There is no real intrinsic difficulty to the problem. I'm no…

The problem is easy. Seriously, it really is.

It's easy in the simplified mental model that you have constructed devoid of real world context. Any engineer worth their salt knows the devil's in the details. I'm going to stop arguing now because you're not even responding to my actual argument. It's not a zen thing, you should be able to get it if you actually read my comments, but just in case you need a koan, ponder this fact that I would bet my life savings on:

There exists a potential feature which could be implemented in Basecamp faster than in your product (and vice versa).

Re: "How hard can it be to implement?"

#66

Post by gaius »

SMrF wrote: post #3
thisisnotmyname wrote: post #2

Is there really no simpler way to solve this problem? "Moving a message needs to move all of the message's comments, and all of the comments' files, and all of the comments' files' versions." Why can't you just change some top level reference in the database? I'm imagining a Projects table and a TodoLists table. Each TodoList has something like a projectID foreign key right? Why can't you just change that and automat…

From the response; "We can't use database transactions because performing a big move would slow Basecamp down for everyone. So we have to log the process of each step of the move, and make it so any failure in the move can be rolled back gracefully. That means a move is actually a series of copies and deletions instead of just changing a field for each moved item"

How amusing. Absolutely not an issue in any grown-up database that implements row versioning/MVCC a la Postgres or Oracle. The sad thing is he (and most MySQL users) probably believe this is inherent to all RDBMSs.

Re: "How hard can it be to implement?"

#67

Post by gaius »

vog wrote: post #51
kristiandupont wrote: post #46

Earlier quoted context omitted.

Should you implement something with an array or a linked list? That depends. Should it be fast to locate an element in the middle? Or should it be cheap to add another element regardless of the size? Ideally, both, but you weigh the pros and cons and choose one. And even if it is the right choice, you might still run into situations where the other choice would have been better and people will comment that your decis…

This is not necessarily about whether the denormalized database structure is appropriate. It is more about: Why the h... doesn't their ORM, or even better their database, already take care of cascading updates? Why does it have to be implemented manually for every code that updates something? (... which is of course expensive and prone to errors)

Exactly. I can imagine that they thought they were being very clever using ORM + MySQL instead of writing SQL to run on a more mature RDBMS. Well, decisions like that often result in you painting yourself into a corner. There's a reason that MySQL is free yet people still pay for Oracle...

Re: "How hard can it be to implement?"

#68

Post by richcollins »

josephholsten wrote: post #28
richcollins wrote: post #10

This would be easy in a graph db. Just move the node and its children come along for the ride.

Not exactly. If you look a bit closer, you'll see that this isn't just a strict child, otherwise they might have managed by swapping a foreign key or something. In a graph db, you'd still have to reconnect dangling edges that no longer make sense, like for comments and users. Also, the transaction rollback issue. Which is to say: tanstaafl.

The comments and user nodes are moved with the parent. It's like moving a folder with subfolders in the filesystem.

Re: "How hard can it be to implement?"

#69

Post by ericd »

jemfinch wrote: post #54
kristiandupont wrote: post #46

Earlier quoted context omitted.

Should you implement something with an array or a linked list? That depends. Should it be fast to locate an element in the middle? Or should it be cheap to add another element regardless of the size? Ideally, both, but you weigh the pros and cons and choose one. And even if it is the right choice, you might still run into situations where the other choice would have been better and people will comment that your decis…

Whatever the case, when I see a programmer doing a linear search through a linked list, I think you must agree that I'm justified in saying that I have no reason, based on that observation, to trust in that programmer's competence. In fact, I think it could easily be argued that in the absence of additional data, it would actually constitute a reason not to trust the programmer's competence. While I fully agree that…

If the worst case size of that linked list is small, then I would say that I would trust that programmer more than the one that throws every searched linked list into a tree structure regardless of size.

In the case of sharding by project, it actually seems like a decent move given that a single Basecamp account has potentially large space requirements (75 GB), and you can't realistically provision enough space on a box to meet all the needs of a bunch of expanding accounts on that box. Being able to throw an entire project onto a new server and assuming that everything associated with a project is on that one server are both nice simplifying assumptions which seem like they would strike a nice balance.

Please stop painting everything with broad black and white strokes, programming and business in general are frequently more about striking the right balance of compromises than about knowing the "best" way to do things. There's usually not a universal "best". 37Signals seem to be doing a marvelous job balancing those compromises between their various disciplines, especially given their massive success with customers.

Edit: This is assuming they're storing attachment files on the same machine, which might very well be wrong. It would be pretty hard for one group to get up to 75GB of todo's and other text content...

Re: "How hard can it be to implement?"

#70

Post by [deleted] »

latortuga wrote: post #38
dasil003 wrote: post #34

Earlier quoted context omitted.

Yes, in your armchair analysis that takes into account none of the issues that they've dealt with in getting where they are today, any past architectural decisions that make this particular feature difficult to implement indicate incompetence. Your confidence probably serves you well (let me guess, early 20s?), but in this case you literally don't know what you're talking about.

Are we really taking cheap shots about age now? This is not how an argument is won and not how we do things around here. Your point stands on its own without ageism.

[deleted]
Post reply on HN