Live data from Hacker News

Removing stuff is never obvious yet often better

gkogan.co

181–190 of 196 posts

Re: Removing stuff is never obvious yet often better

#181

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…

I'm sympathetic to your situation, but it's possible that the senior was still right to remove it at the time, even if you were eventually right that the product would need it in the end. If I recall correctly they have a measure at SpaceX that captures this idea: The ratio of features added back a second time to total removed features. If every removed feature was added back, a 100% 'feature recidivism' (if you gran…

Maybe it's just down to the way the comment was written and it actually played out differently, but the only thing I'd be a bit miffed about is someone more senior just coming in and nuking everything because YAGNI, like the senior guy who approves a more junior engineer's code and then spends their time rewriting it all after the fact.

Taking that situation as read, the bare minimum I'd like from someone in a senior position is to:

a) invite the original committer to roll it back, providing the given context (there isn't a requirement, ain't gonna need it, nobody asked for it, whatever). At the bare minimum this might still create some tension, but nowhere near as much as having someone higher up the food chain taking a fairly simple task into their own hands.

b) question why the team isn't on the same page on the requirements such that this code got merged and presumably deployed.

You don't have to be a micromanager to have your finger on the pulse with your team and the surrounding organisational context. And as a senior being someone who passes down knowledge to the more junior people on the team, there are easy teaching moments there.

Re: Removing stuff is never obvious yet often better

#182

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…

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

You're missing the time other developers will spend trying to figure out why that code is there. When investigating a bug, upgrading, or refactoring, people will encounter that code and need to spend time and mental energy figuring it out.

Recently, I've been modernizing a few projects to run in containers. This work involves reading a lot of code, refactoring, and fixing bugs. Dead code—either code that is no longer called or code that never was—is one of the things that most wastes my time and energy. Figuring out why it's there and wondering if changing or deleting it will affect anything is just tiresome.

Answering "Why" is usually the hardest question. It becomes especially challenging when the original developer is no longer with the team.

Re: Removing stuff is never obvious yet often better

#183

Earlier quoted context omitted.

That's like saying that comparing a veggie burger to a normal burger sucks because neither are ice cream. A/B tests, by definition, test between A and B. It is very likely that neither is the best option. But how will you find the best option if you don't measure options against each other.

The problem is that in 90% of companies the decision is between A/B and not the iterations of them.

I'm going to assume the 90% number was simply hyperbole. Because it's trivially false in any number of ways;

Firstly many businesses have never heard of A/B testing, much less apply rigorous application of it to proposed changes.

Secondly many businesses have found their niche and don't change anything. There's a reason "that's not how we do it here" is a cliche.

Thirdly a whole slew of businesses are greater changing things all the time. My supermarket can't seem yo help themselves iterating on product placement in the store.

Blaming testing in general, or A/B testing specifically for some companies being unwilling to change, or iterate, seems to be missing the actual problem.

Frankly, with regard yo web sites and software I'd prefer a little -less- change. I just get used to something and whoops, there's a "redesign" so I can learn it all again.

Re: Removing stuff is never obvious yet often better

#184

I don't know if this calculator was good or bad, but the rationale sounds superficially ridiculous. > Visitors who didn't see the calculator were 16% more likely to sign up and 90% more likely to contact us than those who saw it. There was no increase in support tickets about pricing, which suggests users are overall less confused and happier. Of course if you hide the fact that your product might cost a lot of money…

Relatedly, there seemed to be no acknowledgement of the possibility of dark incentives: many businesses have found they can increase sales by removing pricing details so that prospective customers get deeper into the funnel and end up buying because of sunk time costs even though they would have preferred a competitor. Example: car dealerships make it a nightmare to get pricing information online, and instead cajole…

To be fair, the pricing is still available in this case: https://www.pinecone.io/pricing/ (though the "Unlimited XXX" with the actual price below in gray might be considered misleading)

Re: Removing stuff is never obvious yet often better

#185
post #153
post #65

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?

Once they’re using the product they can see their actual usage and cost metering. So they can either extrapolate that to larger scale or test it at scale for a short time to see hourly/daily cost and then extrapolate for the month or year. In other words it’s not much of a burden and they get much more reliable information.

It's not a burden to actually spend time setting up the system? This is usually a non-trivial amount of work.

Re: Removing stuff is never obvious yet often better

#186
post #175
post #173

Earlier quoted context omitted.

In my post history, I asked about newsletters and newsletter popups, and a few people confirmed that they work really well. The goal is to get paying customers. We discerning readers are the high effort, low reward cohort that aren't worth losing sleep over.

> In my post history, I asked about newsletters and newsletter popups, and a few people confirmed that they work really well. Ignoring for now that’s 100% anecdotal and that “a few people” is far from enough to make definitive claims, what post history are you referring to? Do you have a link? > The goal is to get paying customers. We discerning readers are the high effort, low reward cohort that aren't worth losing…

You're being overly pessimistic. It's not exploitation. You ask people if they want a thing and they say yes. It works predictably better than not shooting your shot.

Call it anecdotal evidence if you will. The matter of fact is that it seems to work well enough for people to keep doing it.

Re: Removing stuff is never obvious yet often better

#187
post #181

Earlier quoted context omitted.

I'm sympathetic to your situation, but it's possible that the senior was still right to remove it at the time, even if you were eventually right that the product would need it in the end. If I recall correctly they have a measure at SpaceX that captures this idea: The ratio of features added back a second time to total removed features. If every removed feature was added back, a 100% 'feature recidivism' (if you gran…

Maybe it's just down to the way the comment was written and it actually played out differently, but the only thing I'd be a bit miffed about is someone more senior just coming in and nuking everything because YAGNI, like the senior guy who approves a more junior engineer's code and then spends their time rewriting it all after the fact. Taking that situation as read, the bare minimum I'd like from someone in a senior…

There are a lot of cultural factors that could change my perspective here, but this is a reasonable criticism of the senior guy's approach.

Re: Removing stuff is never obvious yet often better

#188

Earlier quoted context omitted.

I designed an internal system that optimises for long term outcomes. We do nothing based on whether you click “upgrade”. We look at the net change over time, including impact to engagement and calls to support months later and whether you leave 6 months after upgrading. Most of the nudges are purely for the customer’s benefit because it’ll improve lifetime value.

That's the only thing I was thinking with their A/B test. The calculator might immunize against unhappy customers later on. I think they could've looked at something like the percentage of customers who leave one or two billing cycles later.

Unfortunately, there's never enough time to run a proper experiment - we want answers now! Who cares if they're the right answers. Short-termism can't wait two months.

Re: Removing stuff is never obvious yet often better

#189
post #123
post #69

Earlier quoted context omitted.

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.

The issue is that A/B testing only looks at outcomes, not reasons. There is a possibility that having the sign-up button above the fold wasn't the contributing factor here, or that it was only a contributing factor. Having to scroll through an estimate may lead a potential customer to believe that pricing is too complex or, worse, that the vendor is trying to hide something. Perhaps there are other reasons. The probl…

If it was your average modern startup page where you have to scroll down 3 screens to see anything besides generic marketing drivel and licensed stock photos of smiling corporate drones, of course reducing whitespace so people can see what the product is about will increase signups.
Post reply on HN