Hacker News Reader

Comment by varjag | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com