6 ms·

The question is what the cost of that fix would be. Once the ticket reaches the developer it's probably quickly done and pays for itself with a handful registra

The question is what the cost of that fix would be. Once the ticket reaches the developer it's probably quickly done and pays for itself with a handful registrations. However getting from support to a developer is the complex part. (Support has to understand the issue and then it has to be routed to the correct team ...)

smt88 6y ago
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.
- varjag 6y ago
  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.
  - korla 6y ago
    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.
    - varjag 6y ago
      Oh wow, editing a hard coded list. Does one need a chisel for that?
      - jedberg 6y ago
        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.
        varjag 6y ago
        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.
        jedberg 6y ago
        Of course they do. But it still takes time, effort, and resources to run through the QA pipeline.
        varjag 6y ago
        https://xkcd.com/277/ https://xkcd.com/277/
      - IggleSniggle 6y ago
        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.
        deleted 6y ago
        [deleted]
  - ZephyrBlu 6y ago
    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.
    - varjag 6y ago
      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.
      - specialist 6y ago
        Maybe they ran out those property list updating chisels.
  - quicklyfrozen 6y ago
    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.
    - specialist 6y ago
      Minimizing turn upkeep (over head) is worthwhile. Ignoring it is ludicrous.
    - arcticbull 6y ago
      > 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.
  - ballenf 6y ago
    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.
    - Klinky 6y ago
      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?
      - strbean 6y ago
        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!
    - wokkel 6y ago
      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.
      - 6y ago
- marta_morena_28 6y ago
  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.
  - Symbiote 6y ago
    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_Numbers.html https://www.stevemorse.org/ssn/List_of_Bank_Identification_N...
- mgkimsal 6y ago
  "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.
- arcticbull 6y ago
  > 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.
  - smt88 6y ago
    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.
    - arcticbull 6y ago
      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.
- Tomminn 6y ago
  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.
  - smt88 6y ago
    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.

smt88 6y ago

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.

varjag 6y ago
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.
- korla 6y ago
  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.
  - varjag 6y ago
    Oh wow, editing a hard coded list. Does one need a chisel for that?
    - jedberg 6y ago
      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.
      - varjag 6y ago
        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.
        jedberg 6y ago
        Of course they do. But it still takes time, effort, and resources to run through the QA pipeline.
        varjag 6y ago
        https://xkcd.com/277/ https://xkcd.com/277/
    - IggleSniggle 6y ago
      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.
      - deleted 6y ago
        [deleted]
- ZephyrBlu 6y ago
  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.
  - varjag 6y ago
    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.
    - specialist 6y ago
      Maybe they ran out those property list updating chisels.
- quicklyfrozen 6y ago
  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.
  - specialist 6y ago
    Minimizing turn upkeep (over head) is worthwhile. Ignoring it is ludicrous.
  - arcticbull 6y ago
    > 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.
- ballenf 6y ago
  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.
  - Klinky 6y ago
    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?
    - strbean 6y ago
      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!
  - wokkel 6y ago
    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.
    - 6y ago
marta_morena_28 6y ago
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.
- Symbiote 6y ago
  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_Numbers.html https://www.stevemorse.org/ssn/List_of_Bank_Identification_N...
mgkimsal 6y ago
"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.
arcticbull 6y ago
> 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.
- smt88 6y ago
  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.
  - arcticbull 6y ago
    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.
Tomminn 6y ago
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.
- smt88 6y ago
  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.