5 ms·

>> This is most likely a bug rather than malicious intent or predatory pricing. Hahahaha. It takes more code to add $10 to a price. It takes a cookie or someth

>> This is most likely a bug rather than malicious intent or predatory pricing. Hahahaha. It takes more code to add $10 to a price. It takes a cookie or something to remember how much they quoted you last time. This explicitly programmed behavior can NOT be a bug, it's a feature that someone took time to implement. The "feature" might be buggy in the sense that's its too obvious and perhaps was only supposed to increase the price once or something, but the overall implementation is almost certainly not a bug.

axg11 5y ago
Do you work in software development? I have, on multiple occasions, introduced bugs that are orders of magnitude wackier than this.
- phkahler 5y ago
  >> Do you work in software development? Yes I do. >> I have, on multiple occasions, introduced bugs that are orders of magnitude wackier than this. Those would make a nice blog post. I've done some stupid things and seen some unexpected results, but I've never encountered the likes of this "accidentally" incrementing price thing. ;-)
  - dahfizz 5y ago
    It could be an index error or a misuse of references, where product B is supposes to be product A + 10. It could be that some local taxes or fees comes out to $10, and the client code does `price += taxes` on page load. There could be code to round up to a $10 increment, and then subtract 2 cents so the prices are all $X9.98, but the rounding logic is incorrect. Since this is JS, they will be using floating point prices. That is a minefield in itself. I'm not saying it's definitely a bug. But it trivially could be.
    - willcipriano 5y ago
      Why do you need to keep state here? I can see calculating the prices dynamicly, but why save and the reuse the result?
      - MiddleEndian 5y ago
        They could be using some node.js framework they don't understand that is silently persisting data.
        dntrkv 5y ago
        Especially if they are using isomorphic JS. Globals / singletons are very dangerous when the JS runs on both the server and client.
      - jonny_eh 5y ago
        Caching.
      - IanCal 5y ago
        * Pull data from API for pricing, later add caching * Modify value to give local amount, not realising it's modifying a cached value * Never test refreshing doesn't change the price
    - sosuke 5y ago
      Verification would be this same test but seeing if the price persists into the "cart" or further down the checkout / shopping process.
    - phkahler 5y ago
      >> It could be an index error or a misuse of references, where product B is supposes to be product A + 10. But why would ANY price be determined in part by the users browser. It gets it right the first time, so why would page reload do anything different? This makes no sense.
      - lupire 5y ago
        It makes no sense, because it's a bug. Why would one package double in price, but the others not change? > gets it right the first time, Maybe, you don't know. It may be adding $10 the first time too.
  - powerslacker 5y ago
    Accidentally the price thing is really easy to do.
- worker_person 5y ago
  It's really fun writing bug that affects motors. Okay slowly turning the 800 pound steel beam 1 degree per minute, and now it's trying to toss it across the room... Boss we need a new $1,000 dollar motor!, and maybe a new wall.
tempoponet 5y ago
It could be as simple as pulling locally cached price data, saying this one is $10 more than the one below it, and then caching that. It would raise the price of itself if they used the wrong array index - something every programmer has done.
- thayne 5y ago
  But why would you cache price data like that?
  - danShumway 5y ago
    > But why would you No idea if GP is correct, but that would not even be close to the weirdest thing I've seen in production code in companies. Very plausible to me that an engineer for a large company could write code like that. Short answer, corporate codebases are messy and weird, and because they are already messy and weird they are therefore breeding ground for even more baffling decisions based on time constraints and partial understandings of already weird systems. Especially in legacy systems, questionable, weird design choices keep producing other questionable, weird design choices until explaining why AJAX requests are getting parsed through hidden input fields or why all of the localstorage fields are Base64 encoded suddenly requires a multi-part, 5-10 minute story about the history of the codebase -- and that's if you're lucky enough to have anyone around who knows the story in the first place. Related to the above, if you're in charge of an engineering team at a company please build more time into your team's schedule for refactoring and code cleanup. ---- To jump off of OP's (at the top of the thread) point, it could also be a bug with malicious pricing. A programmer might have tried to build a dynamic pricing system based on geographic area or whatever and just accidentally read the base price from the same cache they're writing to. And if your followup question is "but why would you read the base price from localstorage instead of from the server, or why would you even have that logic clientside in the first place?" -- then see the first point above. But none of the explanations here would be surprising to me at all. It's not really a debate about whether AT&T alters prices based on stuff like area and customer data, I'd be surprised if someone tried to claim they don't. But like OP said, this doesn't make much sense from a conversions point of view; and it's way more likely to be a bug than it is to be an executive mistakenly believing that raising the price by $10 on every refresh makes people more likely to buy Internet. That executive already has better methods to increase prices: adding hidden fees and service charges, and raising prices behind the backs of long-term customers who aren't checking their bills regularly enough or who are unlikely to go to the trouble and inconvenience of switching or fighting the bill. My suspicion is bug.
mechanical_bear 5y ago
- phkahler 5y ago
  >> You obviously don’t code. over 40 years if you count my kid years and closing in on 30 on the clock. IMHO anyone that thinks "the price magically increments 10 dollars every page refresh" is somehow a typical bug (that made production yet!) should probably quit the field.
  - pwinnski 5y ago
    So I've been coding a few more years than you have, but not many. As a backend dev, this bug makes no sense at all. Having spent a few years with companies using things like Angular and React, I've seen bugs of this type / in this category more than once. Count yourself fortunate that you've missed such things, but this is the norm more often than not.
    - phkahler 5y ago
      >> Count yourself fortunate that you've missed such things... Will do. ... but this is the norm more often than not. I can't tell you how frightening I find that ;-) I did appreciate your comment: >> As a backend dev, this bug makes no sense at all. That affirms my idea that such things should never happen - at least in some contexts. But it leave me wondering what on earth kind of tools are people using for this to be unsurprising?
      - jl6 5y ago
        > such things should never happen The space where things should never happen is fertile ground for bugs, because by definition programmers pay less attention / do less testing when they think failure is impossible :)
  - mechanical_bear 5y ago
    I retract my assertion then. However, there were several possible scenarios proffered in the comments whereby this is an easy bug to create. Mainly an increment setup where it increments itself instead of increments off of a base.
pwinnski 5y ago
> This explicitly programmed behavior can NOT be a bug Um, I know you said you work in software, and the rules say not to doubt you. So I'll press Y and move on. There are so many levels of bugs that almost nothing would surprise me, and this falls very easily within the range of bugs I've witnessed personally. Let's try this: Hahahaha. It takes a single off-by-one errors to accidentally increment prices. It would take a lot of effort to deliberate design a feature that deliberately adds to quoted prices on every refresh, for the purpose of... um... well, that part is unclear. This bug can NOT be explicitly programmed behavior, it's too obvious incorrect behavior to be something someone took time to implement. Yeah, that was easy. Except mine makes sense.
- JumpCrisscross 5y ago
  They may have never coded a pricing system. I haven’t, but I’ve coded trading systems. Typo a dividend or convert and your dumb little bot starts incrementing its offer every millisecond. (The fun is when another bot gets thrown into a complementary loop and the exchange yells at you.) Have a system that e.g. codes a local tax or maintenance allowance run on lookup, or have these data in two systems that try to sync but do it wrong, and you get something like this. (This is not a legitimate pricing strategy. Nobody gets FOMO buying an AT&T plan.)
- jklinger410 5y ago
  I think OP was saying that the price being relative to each user/session is not a bug, but a feature. The bug part is probably that it keeps raising the price on every refresh, rather than just once.

axg11 5y ago

Do you work in software development? I have, on multiple occasions, introduced bugs that are orders of magnitude wackier than this.

phkahler 5y ago
>> Do you work in software development? Yes I do. >> I have, on multiple occasions, introduced bugs that are orders of magnitude wackier than this. Those would make a nice blog post. I've done some stupid things and seen some unexpected results, but I've never encountered the likes of this "accidentally" incrementing price thing. ;-)
- dahfizz 5y ago
  It could be an index error or a misuse of references, where product B is supposes to be product A + 10. It could be that some local taxes or fees comes out to $10, and the client code does `price += taxes` on page load. There could be code to round up to a $10 increment, and then subtract 2 cents so the prices are all $X9.98, but the rounding logic is incorrect. Since this is JS, they will be using floating point prices. That is a minefield in itself. I'm not saying it's definitely a bug. But it trivially could be.
  - willcipriano 5y ago
    Why do you need to keep state here? I can see calculating the prices dynamicly, but why save and the reuse the result?
    - MiddleEndian 5y ago
      They could be using some node.js framework they don't understand that is silently persisting data.
      - dntrkv 5y ago
        Especially if they are using isomorphic JS. Globals / singletons are very dangerous when the JS runs on both the server and client.
    - jonny_eh 5y ago
      Caching.
    - IanCal 5y ago
      * Pull data from API for pricing, later add caching * Modify value to give local amount, not realising it's modifying a cached value * Never test refreshing doesn't change the price
  - sosuke 5y ago
    Verification would be this same test but seeing if the price persists into the "cart" or further down the checkout / shopping process.
  - phkahler 5y ago
    >> It could be an index error or a misuse of references, where product B is supposes to be product A + 10. But why would ANY price be determined in part by the users browser. It gets it right the first time, so why would page reload do anything different? This makes no sense.
    - lupire 5y ago
      It makes no sense, because it's a bug. Why would one package double in price, but the others not change? > gets it right the first time, Maybe, you don't know. It may be adding $10 the first time too.
- powerslacker 5y ago
  Accidentally the price thing is really easy to do.
worker_person 5y ago
It's really fun writing bug that affects motors. Okay slowly turning the 800 pound steel beam 1 degree per minute, and now it's trying to toss it across the room... Boss we need a new $1,000 dollar motor!, and maybe a new wall.

tempoponet 5y ago

It could be as simple as pulling locally cached price data, saying this one is $10 more than the one below it, and then caching that. It would raise the price of itself if they used the wrong array index - something every programmer has done.

thayne 5y ago
But why would you cache price data like that?
- danShumway 5y ago
  > But why would you No idea if GP is correct, but that would not even be close to the weirdest thing I've seen in production code in companies. Very plausible to me that an engineer for a large company could write code like that. Short answer, corporate codebases are messy and weird, and because they are already messy and weird they are therefore breeding ground for even more baffling decisions based on time constraints and partial understandings of already weird systems. Especially in legacy systems, questionable, weird design choices keep producing other questionable, weird design choices until explaining why AJAX requests are getting parsed through hidden input fields or why all of the localstorage fields are Base64 encoded suddenly requires a multi-part, 5-10 minute story about the history of the codebase -- and that's if you're lucky enough to have anyone around who knows the story in the first place. Related to the above, if you're in charge of an engineering team at a company please build more time into your team's schedule for refactoring and code cleanup. ---- To jump off of OP's (at the top of the thread) point, it could also be a bug with malicious pricing. A programmer might have tried to build a dynamic pricing system based on geographic area or whatever and just accidentally read the base price from the same cache they're writing to. And if your followup question is "but why would you read the base price from localstorage instead of from the server, or why would you even have that logic clientside in the first place?" -- then see the first point above. But none of the explanations here would be surprising to me at all. It's not really a debate about whether AT&T alters prices based on stuff like area and customer data, I'd be surprised if someone tried to claim they don't. But like OP said, this doesn't make much sense from a conversions point of view; and it's way more likely to be a bug than it is to be an executive mistakenly believing that raising the price by $10 on every refresh makes people more likely to buy Internet. That executive already has better methods to increase prices: adding hidden fees and service charges, and raising prices behind the backs of long-term customers who aren't checking their bills regularly enough or who are unlikely to go to the trouble and inconvenience of switching or fighting the bill. My suspicion is bug.

mechanical_bear 5y ago

phkahler 5y ago
>> You obviously don’t code. over 40 years if you count my kid years and closing in on 30 on the clock. IMHO anyone that thinks "the price magically increments 10 dollars every page refresh" is somehow a typical bug (that made production yet!) should probably quit the field.
- pwinnski 5y ago
  So I've been coding a few more years than you have, but not many. As a backend dev, this bug makes no sense at all. Having spent a few years with companies using things like Angular and React, I've seen bugs of this type / in this category more than once. Count yourself fortunate that you've missed such things, but this is the norm more often than not.
  - phkahler 5y ago
    >> Count yourself fortunate that you've missed such things... Will do. ... but this is the norm more often than not. I can't tell you how frightening I find that ;-) I did appreciate your comment: >> As a backend dev, this bug makes no sense at all. That affirms my idea that such things should never happen - at least in some contexts. But it leave me wondering what on earth kind of tools are people using for this to be unsurprising?
    - jl6 5y ago
      > such things should never happen The space where things should never happen is fertile ground for bugs, because by definition programmers pay less attention / do less testing when they think failure is impossible :)
- mechanical_bear 5y ago
  I retract my assertion then. However, there were several possible scenarios proffered in the comments whereby this is an easy bug to create. Mainly an increment setup where it increments itself instead of increments off of a base.

pwinnski 5y ago

> This explicitly programmed behavior can NOT be a bug Um, I know you said you work in software, and the rules say not to doubt you. So I'll press Y and move on. There are so many levels of bugs that almost nothing would surprise me, and this falls very easily within the range of bugs I've witnessed personally. Let's try this: Hahahaha. It takes a single off-by-one errors to accidentally increment prices. It would take a lot of effort to deliberate design a feature that deliberately adds to quoted prices on every refresh, for the purpose of... um... well, that part is unclear. This bug can NOT be explicitly programmed behavior, it's too obvious incorrect behavior to be something someone took time to implement. Yeah, that was easy. Except mine makes sense.

JumpCrisscross 5y ago
They may have never coded a pricing system. I haven’t, but I’ve coded trading systems. Typo a dividend or convert and your dumb little bot starts incrementing its offer every millisecond. (The fun is when another bot gets thrown into a complementary loop and the exchange yells at you.) Have a system that e.g. codes a local tax or maintenance allowance run on lookup, or have these data in two systems that try to sync but do it wrong, and you get something like this. (This is not a legitimate pricing strategy. Nobody gets FOMO buying an AT&T plan.)
jklinger410 5y ago
I think OP was saying that the price being relative to each user/session is not a bug, but a feature. The bug part is probably that it keeps raising the price on every refresh, rather than just once.