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

Removing stuff is never obvious yet often better

gkogan.co

Post reply on HN
Print view View original

61–70 of 196 posts

Re: Removing stuff is never obvious yet often better

#61

Post by animeshjain »

gk1 wrote: post #15
makeitdouble wrote: post #12

The general message is interesting. This specific bit kinda gives pause though: > One slight misinterpretation and wrong input and you'd get an estimate that's overstated by as much as 1,000x. Does it also mean that in real world usage, one slight misinterpretation or misevaluation of your metrics and you're liable to 1000x more than you planned to ? I totally see this as a reality of online billing systems. I've mis…

(Author here) > Does it also mean that in real world usage, one slight misinterpretation or misevaluation of your metrics and you're liable to 1000x more than you planned to? Unlikely. You can see why in these two examples that really happened: One user I spoke with said they assumed "queries per second" is calculated by (number of searches) x (top-k for each search), where "top-k" is the number of results they want…

somewhat ironically, adding these examples to the post would make it more valuable :)

Re: Removing stuff is never obvious yet often better

#63

Post by dmacj »

refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

What was the DB migration required for those particular columns?

I presume this was not the only time such a migration needed to be done to add columns. Is it possible that as new features emerge, new columns and migrations will need to be done anyway and one more or less migration would make less of a difference on the grander scale?

Re: Removing stuff is never obvious yet often better

#65

Post by whakim »

I don’t get it. Presumably the pricing model didn’t change, so all you’ve done is push the burden of doing the math onto the user (or more realistically, hope they just don’t even bother?) If users are frequently estimating costs that are off by orders of magnitude, surely the correct response is to change the pricing model so it’s easier for customers to understand?

Re: Removing stuff is never obvious yet often better

#66

Post by shubhamjain »

refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

In most cases though, anticipating requirements results in building things you don't need. And if you do need them, you usually end up needing a very different form of it. The worst codebase I have worked on is the one that was designed with some complex future-use in mind. In your example as well, the codebase only required columns a year later. So I think removing all chunks of code that anticipate a future need sets the right precedent, even if you end up needing it eventually.

Re: Removing stuff is never obvious yet often better

#67

Post by citizenpaul »

ramshanker wrote: post #9
kmoser wrote: post #7

Earlier quoted context omitted.

The article states that the biggest factor was user misunderstanding of the options, not so much the number of different options. In other words, if they offer option A at $x and option B at 10*$x, if most users mistakenly think they need option B, the calculator is misleading. Also, I'm a big fan of "contact us for pricing." It's annoying for users who are window-shopping and want a quickie ballpark, but it helps yo…

>>> I'm a big fan of "contact us for pricing." I have opposite feeling about them. They are like open invitation to give the sales guy a window of opportunity to look up your company website, and markup the price accordingly.

Exactly. Its an invitation to the used car salesman circus. I do t have time to play games with a salesman for the next two weeks. If a company doesnt have at least ballpark pricing available upfront they never hear from me and dont even know they lost a potential customer. Only huge entrenched companies can get away with that long term. That and single suppliers.

Re: Removing stuff is never obvious yet often better

#68

Post by blackoil »

shubhamjain wrote: post #60
CookieCrisp wrote: post #56

Earlier quoted context omitted.

I feel like that example is missing some context - if signups did increase then their experiment was successful - we aren’t here to make pretty pages, we’re here to make money.

The problem is that it's easy to prove that signups are increasing, and lot harder to prove that there was a measurable increase in number of paying users. Most A/B tests focus on the former, very few on the latter. We had a free plan, and most users who signed up never made a single API request. So, assuming that the increase in signups is driving more business is just foolhardy.

You can always track signup/paying-users ratio. Purpose of landing/pricing page is to get the users to sign-up. Unless some dark pattern or misinformation is used to confuse users into sign-up, more users is a positive thing.

Re: Removing stuff is never obvious yet often better

#69

Post by strken »

bruce511 wrote: post #54
shubhamjain wrote: post #51

Earlier quoted context omitted.

Absolutely true! An A/B test enthusiast in our team once significantly reduced padding on the pricing page to bring the signup button above the fold and used the increase in signup button clicks as a proof of success of the experiment. Of course, the pricing page became plain ugly, but that didn't matter, because "Signups are increasing!!" In this case, I do agree that the calculator is a bit daunting if you're not u…

>> Of course, the pricing page became plain ugly, but that didn't matter, because "Signups are increasing!!" I'm not sure I'm following you here, so perhaps you'd care to elaborate? The GP critique was that it was perhaps just creating a problem elsewhere later on. I'm not seeing the similarity to your case where the change is cosmetic not functional. The issue of whitespace (padding) is subjective (see the conversat…

I think one problem is that a better design would move the button above the fold without ruining the spacing, and therefore achieve a better result with even higher lift, but someone focused on just the numbers wouldn't understand this. The fact that the A/B test has a big green number next to it doesn't mean you should stop iterating after one improvement.

Re: Removing stuff is never obvious yet often better

#70

Post by chii »

refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

> But the original work had taken me maybe an hour. And the cost of keeping the data around was approximately zero. It seemed he didn’t consider that.

i guess this is very illuminating - you have to predict the cost of adding YAGNI, before doing it. A low cost YAGNI feature might actually serendipidously become useful.

I feel this is the same principle as random side projects, not done out of necessity but out of curiosity and/or exploration.

Post reply on HN