from Hacker News

We Just Undid Three Months of Dev work. Here's What We Learned.

by acl on 10/7/09, 6:13 PM with 30 comments

  • by stingraycharles on 10/7/09, 6:57 PM

    I think the real lesson to learn here is to never assume anything. They assumed performance wouldn't be a problem, so they didn't test for it when prototyping, and they didn't make those tests part of their development cycle.

    It's tough, these things, especially if you're talking about a feature you personally appreciate a lot. The article talks about the performance problems leading focus away from actively marketing these solutions, which makes me wonder: if properly marketed, would this have been a killer feature ?

    The fact that they decided to get rid of it suggests no. However, are they putting the code in the freezer for a while until they fix these issues and re-release it ? Or is it simply a problem that can only be properly solved by giants like Google ?

  • by megamark16 on 10/7/09, 7:54 PM

    I wish I could send this to my boss. The functionality I'm working on right now was requested by a single client and is really only applicable to their unique billing situation. Why am I spending so much time on something that is going to have so little payoff, and yet which adds so much additional complexity to the system? But I've only been here a month and I don't feel like I can cast a dissenting voice. Maybe I'm just a coward.

  • by mr_luc on 10/7/09, 11:40 PM

        The database operations on the nested data were 
    just taking too much processing power.
    Given that this is Rails, and given that it's certainly SQL involved here, I just have to ask (and I know the answer is probably "yes") -- did you try implementing nested sets?

    I ask because my experience has been that nested data is (with the kinds of nested data I've been handed, anyway) not a performance problem. Selects and updates of nested data can be as responsive as any range query on flat data, and when it comes to managing the performance of inserting new nodes, deleting or moving subtrees, there are a lot of options depending on what you want to optimize for (like spreading out the range from 1 to the max integer supported and periodically re-packing; that way, inserting leaves and any kind of deletion is as fast as with flat data).

    I'm curious about what your nested data looked like. Sorry to get distracted on a minor point, but I'm intrigued! When I'm developing, I just always feel as though I should only worry when I start seeing data that has to be a graph and can't be represented as a tree, but as long as it actually is hierarchical then I won't have to worry about speed too much; but now I'm wondering if that intuition will bite me.

  • by fizx on 10/7/09, 6:42 PM

    Haha, I'm doing the same thing right now. When one feature costs > 10% of dev time, and you can afford to get rid of it, do it! In my case, I was spending 50%+ of my time for a few weeks on stability issues caused by a feature that <10% of my users need. Bye!

  • by davidmathers on 10/8/09, 4:22 AM

    Short version:

    In our case, the move from flat data to nested data was the killer...We came up with a sweet way of storing the nested data and abstracting away most of complexities of dealing all kinds of data...However, the load on our database was far more than we envisioned...MySQL.

  • by nestlequ1k on 10/8/09, 5:45 AM

    Great, as a paying customer of scout they are telling me their going to now focus on getting new customers instead of servicing the ones they have.

    Might make sense from a business standpoint, but probably something you dont want to advertise :-).

  • by amichail on 10/7/09, 8:12 PM

    Just a meta comment about these lessons learned posts. The motivation behind these is to promote the product in question and one must therefore take them with a grain of salt.

    Peer reviewed research is more reliable.

  • by edw519 on 10/7/09, 8:37 PM

    This reminds me of one of my biggest internal conflicts: when to optimize.

    "Premature optimization" has earned a negative reputation because it has a tendency to inflate dev schedules unnecessarily.

    So I tend to just crank something, anything out just to have something. Once you can see what you have, it's often a lot easier to modify than come up with in the first place.

    OTOH, I like to think that everything I build is a foundation for the next thing to be built upon it. I am constantly getting bitten in the ass by some grossly underperforming building block. If a prototype runs poorly a dozen times, it's a concern. If the same code runs poorly a million times, it's a disaster.

    It's a constant trade-off. Get something running vs. build solid building blocks. Make a mistake one way and never release. Make a mistake the other way and have a time bomb to clean up. Sounds like OP has a lot of the same issues.