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

http://blog.scoutapp.com/articles/2009/10/06/we-just-undid-three-months-of-dev-work-heres-what-we-learned

by acl • 17 years ago

98 30 17 years ago

blog.scoutapp.com

fizx2• 17 years ago

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!

smokinn• 17 years ago

On the other hand, punting on any hard problems just makes it that much easier for your competitors.

zaidf3• 17 years ago

You mean hard problems that matter.

There are a lot of hard problems startups try to solve which no one cares about. That's the trap to avoid.

Fixing something hard does not inherently make your company valuable in the marketplace.

stingraycharles2• 17 years ago

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 ?

acl3• 17 years ago

They assumed performance wouldn't be a problem

We did pretty extensive performance tests, but not for long enough. We load tested tested for hours at a time, and the problems started to show up after days of production load and really compounded after that. It's probably a topic for another post, but the performance of database tables with a lot of churn (rows being frequently inserted and deleted) really degrades over time.

stingraycharles2• 17 years ago

Guess that's my bad for assuming you thought performance wouldn't be a problem. :-)

fizx2• 17 years ago

> ... never assume anything ...

Maybe you meant "Question your assumptions, often." You can't get anywhere constantly verifying things ahead of time. In the extreme case, imagine writing a test suite for printf just to be sure it works as advertised.

The way forward for a startup is to make only the right assumptions. Failing that, make as many assumptions as possible, but correct the failed ones in a reasonably short amount of time. Some minimal cost/benefit analysis on the assumption would also be good.

camccann• 17 years ago

Failing that, make as many assumptions as possible, but correct the failed ones in a reasonably short amount of time. Some minimal cost/benefit analysis on the assumption would also be good.

As a corollary to this, try to arrange that any failures will occur as quickly and obviously as possible. For instance: Component X, which is essentially a black box to you, will be a small but critical part of your project. You don't have time to extensively test it, so you make assumptions about its behavior. Ideally, you should start integrating Component X into the full project immediately such that it's heavily used in development and testing environments, so that any violations of your assumptions will show up incidentally to other work.

On at least a couple occasions, I've been bitten by assuming that a Component X (which I thought I understood) would do what I expected and thus leaving the final integration until near the end of the project. This sounds like an obvious, easily avoided mistake, but it's surprisingly easy to make in the heat of the moment.

NathanKP• 17 years ago

These are some really good points to keep in mind. I'm working on a fairly serious website system for a client right now and just reading over the article and the comments here makes me wonder if I should perhaps think ahead and make sure that I don't have to end up rewriting things.

At the moment I feel that my code is fairly future proof, but the truth of the matter is that when it comes to performance its hard to tell how things will work out in the long run.

megamark16• 17 years ago

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.

chriskelley2• 17 years ago

Being vocal about imperfections in the development cycle and suggesting improvements that matter to the bottom line is not dissent.

It's important to have open communication about this very topic - it improves the pipeline and keeps margins where they need to be. Be confident and prepared with data, and make yourself an asset to your company, not just a keypusher! :)

cmos• 17 years ago

When discussing the merit's of this feature be open minded that you may not have all the information they had in deciding to implement it. Perhaps this is heavily requested by the sales department or by other customers further up the pipeline. Maybe the company threatened to take their business elsewhere.

It's always less obnoxious to approach potentially illogical situations by giving someone the benefit of doubt. So, while you collect your 'data', also do some brainstorming on area's where the feature your adding makes a ton of sense, and might even open up new sales channels or markets.

Instead of assuming there's been some catastrophic mistake you must remedy, and instead of assuming that management puts no value on your time, try assuming that they have good reasons for it that you, especially being their for a month, might not have been fully explained. Quite often the problem is communication, not intent to waste money.

At the end, if all your effort is for seemingly insignificant return, smile and do an amazing job. Repeat until you grow weary and embattled, then leave for another job with a different set of problems.

kogir• 17 years ago

I don't know the details of your particular situation. That said, I've been in situations where that "single client" accounts for 75% of the user base and more of the revenue. Sometimes you give the client anything they ask for :)

amichail2• 17 years ago

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.

johns2• 17 years ago

If you want to dismiss a post on that theory, you should remove the links to your products in your profile.

amichail2• 17 years ago

There is no need to dismiss all such posts. Some may be interesting/educational regardless.

But you do need to keep in mind the primary motivation behind them -- marketing.

edw519• 17 years ago

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.

mr_luc2• 17 years ago

    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.

acl3• 17 years ago

did you try implementing nested sets?

The big thing we needed to do was a rolling archive to progressively broader timeframes. As metrics come in, we keep every single datapoint for the first 6 hours. After 6 hours, data gets rolled up into 5-minute archive. Each datapoint in the 5-minute archive then contains avg, min, max, etc for all the points that lived within that 5-minute span.

The archiving carries on through progressively broader windows as time goes on -- a 10-minute archive, 1-hr archive, etc. This progressive aggregation is the only sane approach to storing the massive amount of data we get. And, it reflects the need for higher resolution for recent events -- it's rare you need to see what happened at one exact minute 6 months ago.

It was this progressive archiving that bit us, specifically as DB performance degraded over time with lots of insertions/deletions. Nested set didn't/wouldn't help with aggregation costs and degradation from churn during the archiving process.

Hope this helps -- I'm going to try to do a more technical post on this in the future.

mr_luc2• 17 years ago

Huh, that's interesting. I guess I've never worked with really "churny" data like that before.

Sure, sometimes I've had cleanup/integrity/whatever tasks that run every few minutes, but the amount of records affected has always been pretty small.

That's an interesting conundrum. See, this is why we're all messing around with Cassandra et al; sometimes, in SQL, the answer is "don't do that", because it'd be too hard to tailor the db's behavior to suit your needs. Although frankly, with a design that deletes and updates a significant percentage of records in the system on a certain schedule, I can see any number of storage solutions having trouble.

That's interesting. I'll be thinking about this at "work" today. ;) I have a bunch of comments, but they're of the half-baked "oh, what about this?" variety.

davidmathers• 17 years ago

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.

nestlequ1k• 17 years ago

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

acl3• 17 years ago

Actually we're also able to spend a lot more time now on things that really matter to our customers -- things that customers request, like more graphing options and better support for cloud instances. The cloud functionality is already available, and graphing is coming up fast. It's a real pleasure to finally have time to address these things, in addition to the sales and partnership efforts.

Also, performance is significantly better since we simplified the architecture (http://blog.scoutapp.com/articles/2009/10/01/simplify-get-an...), which benefits customers old and new!

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

Related Stories