Color me skeptical.
I built web sites for a mid-sized B2B and B2C company, and had to build all kinds of games into the pricing.
Refreshed the page more than three times? That's a price change.
Returned to the same page 24 hours later? 36 hours later? 72 hours later? Price change. Price change. Price change.
Using a tablet? Price change.
Connecting from an IP address believed to be in a particular geographic region? Price change, and inventory change.
An unintended side effect of all of this was that it gave the illusion that pricing was dynamic based on supply and demand. It wasn't. There was no link between inventory and pricing. It was all games based on the user.
But these were luxury items. The cheapest item in the inventory was $5,000ish. With add-ons, they could go up to $30K.
Taking it a step further: a browser extension that tries several scenarios (like Honey, but just for re-fingerprinting and stuff... can an extension make a request that suppresses/manipulates cookies only temporarily?) as you're shopping.
And I doubt that these quoted prices have any relation to the actual bill that they will eventually send.
But at least once in the last 5 years it was exact to the penny. So there's that.
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.
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. ;-)
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.
* Modify value to give local amount, not realising it's modifying a cached value
* Never test refreshing doesn't change the price
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.
> gets it right the first time,
Maybe, you don't know.
It may be adding $10 the first time too.
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.
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.
This is the first time reading HN has made me scared to live on this planet!
A) like 2 or 3 people total care about them way more than they're obligated to and keep them from falling over,
B) it turns out that in many instances people just don't exploit or crash stuff, and broken systems can take a while to fail.
----
That could be a longer conversation and it's not necessarily all pessimistic; the reality of how software (and systems in general) get built is one of the reasons I don't have a lot of patience for people who say there aren't any ways they can contribute to or improve anything and that the world is too connected or competitive now for people to make a difference. There's a ton of stuff to do and improve in most systems regardless of your talent level and there is no shortage of small but really impactful things that people can do around infrastructure, even if it's as simple as documenting how systems work.
But I'm dead serious about this: internalize that real world systems are messy and that everyone involved in them is doing car maintenance on a still-moving vehicle. Internalize that systems decay over time and that as things become messy, they get messier at a faster rate. Internalize that this is not an exception, but the rule. All systems and codebases that are seeing regular development by nature decay and become unmaintainable unless you expend extra energy to keep reinforcing them, pruning them, and refactoring them. And it's not as simple as hiring good programmers, messy systems actually have momentum towards messiness, and regardless of who you hire they'll spend the majority of their time just keeping the system from falling over.
That is an incredibly important principle about the world for people to understand -- both because it helps make sense of a lot of the world and because internalizing it will make you a better manager if you're ever in that position.
It also helps with evaluating security, because it's one thing to say that extra data storage and processing might increase security risk by multiplying attack vectors, and it's entirely another thing to actually have a sense for how much extra risk of bugs/mishandling/exploits each extra layer of software and corporate handling adds to data. At the same time, it also helps with understanding threat models and managing expectations, because you realize that very few things in the world are actually secure, but that for some reason (absent coordinated effort or a lot of attention) they very often don't get exploited or destroyed, and that there are ways to mitigate that kind of inescapable ambient risk.
Not in the web space but I've seen similar with using pythons lrucache as using that on a function modifies the programs behaviour (if you mutate the returned value, you're in trouble).
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.
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.)
Not in $10 increments every refresh though, that's most likely badly coded.
If anything, it seems one should slightly -lower- prices when suspecting a customer is shopping around.
That could be the AT&T motto. See most everything they have done in the past 15 years.