Hacker News Reader

Comment by smt88 | Hacker News Reader

I completely understand why you see this as a 30-min fix, and therefore they should just knock it out.

That's not how they would likely see it. If their devs are 100% utilized (which I'm sure they are), then fixing any issue -- even a 30-min one -- is going to mean that a different issue is delayed.

The question becomes this: at what point is fixing this issue more valuable to the company than any other issue the same dev could work on?

And the answer is possibly "never", depending on what high-impact bugs, features, or technical debt they have on their priority list.

View on HN

You rationalize dysfunction into a strategy.

It's not like they are doing Moon landing there 24/7. It's a simple bug with direct impact on the revenue. They should take a half hour break and fix it.

I think you vastly oversimplify how easy this fix is likely to be. For all we know this may mean touching code in multiple repos, each with hard-coded lists of which cards are supported for some case or another. At least that is what it would mean to change something like this where I am now.

Oh wow, editing a hard coded list. Does one need a chisel for that?

That is not how things work in the real world. Sure, the fix itself might take 30 minutes. But then you have to validate it. And run a canary. And crosscheck your revenue numbers to make sure it didn't have an adverse affect elsewhere.

That's a lot of work for something that will probably mean very little extra revenue.

I assume they already have the quality assurance pipeline in place at Tinder and don't need to reinvent it from scratch for every bug report.

Of course they do. But it still takes time, effort, and resources to run through the QA pipeline.

https://xkcd.com/277/

Depending on the amount of technical debt, it could very well be a number of hard coded lists in a number of projects that may be under multiple teams and which may or may not include first party code. It’s not that fixes like this should be hard, it’s that sometimes they are hard despite themselves, for organizational reasons.

Edit: just for clarity, I’d love to fix this bug myself. I also have a million other easy fixes that I’d like to do and I have a manager to help me prioritize them.

It's not just about time, but focus as well.

Other tasks might also be more critical to revenue generation.

At the end of the day, there are always going to be some issues left by the wayside so I think you really have to pick your battles.

It's a 100% reproducible, mentally unchallenging, revenue impacting bug, which is frankly a rare combination. There is no excuse in not fixing it, unless you imply the thousands of Tinder devs are in core meltdown situation all the time.

Maybe they ran out those property list updating chisels.

How is it dysfunction to keep your devs focused on the tasks you've already identified as the most important?

I can't imagine how producing a PR for this with test cases, getting it reviewed, then shepherding through a typical QA/Staging/Prod pipeline would take less then a day for any code base of reasonable complexity.

Perhaps it wouldn't literally take 8 hours, but the focus shift of working on this would likely keep a dev from making much progress on other issues that day.

> How is it dysfunction to keep your devs focused on the tasks you've already identified as the most important?

Because software is never that cut and dried. There's what supporters think is important, what PMs think is important, what front-line engineers think is important and what leadership thinks is important.

These priorities are frequently different and their actual impact is quite often disjoint from their position in the organization.

Minimizing turn upkeep (over head) is worthwhile. Ignoring it is ludicrous.

They didn't claim it wouldn't impact revenue. Just that there are probably bigger issues that impact more revenue that should be worked on first from a purely ROI point of view.

If and when this issue has a higher ROI than anything else, it should be worked on. The flow of new issues with higher ROI may prevent that from ever happening.

I think every developer can easily name 5+ minor bugs in a product they're working on that they know exist and know roughly how to fix, but may never get around to fixing. Or maybe I'm the weird or unlucky one, but that's been true of every production software I've ever worked on.

What can be argued strongly, I think, is that ROI calculation should take into account secondary effects such as the app's reputation in the country or the appearance of discriminating against a country.

Hopefully there is some good logic and systems in place to actually calculate ROI, and it's not just a PM chasing trends and pushing out new features based on their gut.

I wouldn't say a user-facing bug that prevents collection of revenue is minor.

It's also a little alarming this isn't caught via QA or automated tests. Did this ever work? What other stuff is slipping through? Are we sure the report even escaped support and got triaged?

Financial systems are an absolute nightmare, so it doesn't surprise me that some oddball detail in a small country eludes tests. Pretty much every processor, network, and country has a million of those oddball details, and they change regularly.

At work, the platform I have to deal with has dozens of fields on every request and response that are specific to Brazil!

There is a secondary effect here besides ROI: image. In my mind I now link LinkedIn to "not even able to handle a creditcard payment". Get enough of those and ROI gets impacted.

This one isn't LinkedIn.

> Had a similar experience with Tinder

But I agree with your overall point.

> That's not how they would likely see it. If their devs are 100% utilized (which I'm sure they are), then fixing any issue -- even a 30-min one -- is going to mean that a different issue is delayed.

This has not been my experience.

If you work at a company where it's possible, I strongly suggest shadowing a supporter for a day. You'll leave with a 5 page long rage-list of issues that weren't adequately captured (and would take you a few minutes to knock out) and a new relationship established that will help unblock that bottleneck of information flow.

IME, this is in part because supporters aren't as familiar with the technical aspects and don't know how to frame the issues they encounter in a way that would get traction with either PMs or engineers. As such are not well prioritized relative to issues that are fleshed out technically. I've worked at a company where supporters were spending huge amounts of time resolving issues that I knocked out in 5 minutes after shadowing and materially improved their operational efficiency.

In a word, what's missing is a culture of ownership.

I think you mean "customer support" when you say "supporter". If not, please disregard.

Tinder doesn't offer much customer support. They're definitely not spending a substantial amount of time on issues that affect the subset of users that use Danish cards, don't pay through the app, and have one of the cards that has this issue. If you told me the number of affected people was under 5,000, I would believe you.

Yep, the place I used to work referred to "customer support" as "supporters." I assumed the term was used more broadly than it appears to be, my bad.

I'm curious who handles those emails. I'm putting myself in the position of a software engineer at Tinder, I personally would have gotten care-mad enough to fix it. I go out of my way to get to know customer support folks where I work so I can get better insight into how people are actually using the product and where the pain points lie.

This is absurd. The return on investment for a bug like this must be extraordinarily high. The OP can fix it themselves by changing a string in the developer console.

A permanent new revenue stream from an entire country for the price of 1/16 of one employee's workday.

What kind of fires are burning at Tinder for that to not be a no brainer?

Side note: if there are any devs here from Tinder, I recommend you go fix this on your own initiative and get yourself some quantifiable money made for your employer for your next performance review.

1. It's not an entire country. It's people who use a Danish card and can't/won't subscribe through the Play Store. That's probably a tiny number of people.

2. Fires are almost always burning when you're supporting an app with millions of users expecting instant functionality, including instant messaging. They're also constantly working against bots and spammers.

"features" is the wildcard there.

People who have already demonstrated they're trying to give you money is a relatively known payoff when that bug is fixed. "New features" that may never see the light of day, or may actually have a negative revenue impact... those are somehow sexier and often manage to take priority over mundane issues like... hundreds of peoples' payments failing over a month.

Fixing an issue around being unable to pay with a credit card is likely anything but a 30 min issue, unless there is some triviality happening, like a config issue. But even then you need to add tests for this. A day or two is the absolute minimum and that would be if this is just a config issue. If it's not, then think of weeks.

It should be fairly trivial.

From the issue as described, the value "visa" worked, but "visadankort" didn't. Denmark's earlier, national debit card system is called DanKort. Nowadays, almost all DanKort cards are issued through Visa, so they are "Visa DanKort" -- within Denmark, there's the option to bypass some sort of fee for a lower cost of processing.

Presumably the value "visadankort" is there to distinguish these cards. However, they can be processed exactly as normal Visa cards.

This is not unique to Denmark, there are a list of card prefixes like this (see 4571 for DanKort[1]), but perhaps the different processing fees in unusual.

[1] https://www.stevemorse.org/ssn/List_of_Bank_Identification_N...

Reply on news.ycombinator.com