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

161–170 of 196 posts

Re: Removing stuff is never obvious yet often better

#161

Post by QuantumGood »

lucianbr wrote: post #130
QuantumGood wrote: post #90

Earlier quoted context omitted.

Either accepting or dismissing the number without understanding its purpose or source can also be arrogance, but I agree that throwing a number out without any additional data is of limited, but not zero, usefulness. When I want to know more about a number, I sometimes seek to test the assumption that an order of magnitude more or less (1.5%, 150%) is well outside the bounds of usefulness—trying to get a sense of wha…

No, dismissing something that is claimed without evidence is not arrogance, but common sense.

I think we're getting hung up on the concept of dismissing. To question skeptically, to ask if there is evidence or useful context, to seek to learn more is different than to dismiss.

The 5 Step Design Process emphasizes making requirements "less dumb," deleting unnecessary parts or processes, simplifying and optimizing design, accelerating cycle time, and automating only when necessary.

Musk suggests that if you're not adding requirements back at least 10%-15% of the time, you're not deleting enough initially. The percentage is an estimate initially based on experience, and now for several years based on estimates from manufacturing practice.

Re: Removing stuff is never obvious yet often better

#162

Post by ValentinA23 »

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…

I get what you mean. However other comments raised some valid points too. It's just a few hours of works . I think what matters a lot more is when these kind of anticipated features do not add up to constant gains (which in your case, setting aside the fact that this senior engineer rolled back your tactful additions, would be the time it takes to run the prod DB migrations, since this is what differs between your early and late implementation). More often than not an architectural choice will impact n features orthogonally with respect to other potential features. If it takes you 2 days of work to implement that particular transversal feature, the time it will take you to implement it across all "base" features will be 2n days of work. Stuff like class inheritance will allow you factor that into, say 2 days + 10n minutes. I witnessed disasters because of situations like this where stuff that would have taken me days to implement (or even hours) took 6 months. And the main reason for this is that another team was tasked with doing this, and they didn't know that part of the code base well, which, because everything had to be super "simple" ("easy" would fit better), no class hierarchy, everything super flat, each base feature taking up thousands of lines across several microservices in the hope that anybody could take over, was a slow, dreadly, soul crushing job. Members of the previous team said it would have taken them 2 weeks (because they had a long experience with the spaghetti dish). I re-implemented the program at home in a weekend (took 3 month to code): the required change would have taken me an hour to code, and a fews day of integration to change those n base features (but because I had a leetcode-complex, very expressive architecture, and knew the domain very well). It took the new team 6 months. 6 months ! And I think they only managed to implement one feature, not all of them.

Result: disgruntled senior employees quitted and were replaced with juniors. 3 month later, overtime was distributed across the tech department, killing the laid back 4-days week culture that was put in place to attract talents, the employee unionized, some more quitted, and about a year later, upon failing to hire back these productive elements, the COO was fired.

Re: Removing stuff is never obvious yet often better

#163

Post by neonz80 »

jmathai wrote: post #45
nxicvyvy wrote: post #44

Earlier quoted context omitted.

Wireshark is a pretty bad name to choose.

Yeah - I didn't think there would be confusion with the networking tool but based on feedback we're receiving...I was wrong. We're considering options including changing the name.

I guess Ethereal is available :)

Re: Removing stuff is never obvious yet often better

#164

Post by jayd16 »

ibash wrote: post #16

> Before long, a dedicated Slack channel was created, which accrued over 550+ messages representing opinions from every corner of the company. Another few thousand words and dozens of hours were spent in meetings discussing what we should add to the calculator to fix it. This is a symptom of over hiring. Too many people removes agency. When people lose sight of what's actually important and feel that they must reach…

It's at least what happens when you run a design discussion in a channel with the whole company.

Even design by committee is limited to the committee.

Re: Removing stuff is never obvious yet often better

#166

Post by teqsun »

jmathai wrote: post #45
nxicvyvy wrote: post #44

Earlier quoted context omitted.

Wireshark is a pretty bad name to choose.

Yeah - I didn't think there would be confusion with the networking tool but based on feedback we're receiving...I was wrong. We're considering options including changing the name.

You're in a niche(ish) space, that doesn't have a lot of general overlap with HN.

I can say "I wish someone made a cheaper alternative to the Domino" and anyone in the space will understand what you mean instantly. But from an original analysis others might of told Festool that it was a bad name that will confuse people.

Re: Removing stuff is never obvious yet often better

#167

Post by ahoka »

ValentinA23 wrote: post #162
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…

I get what you mean. However other comments raised some valid points too. It's just a few hours of works . I think what matters a lot more is when these kind of anticipated features do not add up to constant gains (which in your case, setting aside the fact that this senior engineer rolled back your tactful additions, would be the time it takes to run the prod DB migrations, since this is what differs between your ea…

My takeaway here is if you hire domain experts, then trust them when they say you are going to need something.

Re: Removing stuff is never obvious yet often better

#169

Post by scott_w »

mquander wrote: post #22

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…

That’s why you need domain experts and clear explanations and hypotheses before you experiment, otherwise you’re throwing shit at a wall to see what sticks.

Companies can continue to monitor cohorts to compare retention to check the potential outcomes you highlighted.

Re: Removing stuff is never obvious yet often better

#170

Post by gwbas1c »

kmoser wrote: post #7
jclulow wrote: post #2

Perhaps removing a pricing scheme so complicated that it literally can't be modelled usefully by the customer would be even better?

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…

> 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

Don't underestimate those kinds of customers.

For example, an ad for custom tile showers showed up in my feed. I just wanted to "window shop" the price, so I could get an idea if it was something I wanted to do, and plan when to do it.

I filled in the form with a "I'm just looking for a ballpark number, please don't call me."

No response.

Salespeople just don't understand how irritating phone calls are when you're collecting data: Whatever I'm doing at any given moment significantly more important than dropping what I'm doing to answer the phone. This is especially important if all I need to know is a ballpark number to know if I'm interested in having such a phone call.

Post reply on HN