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.
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.
>> 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.
This is the first time reading HN has made me scared to live on this planet!
I'm not sure if it should make you scared or not, but it is good for people to internalize that many if not most systems in our world are (sometimes literally) held together by duck tape and often function purely because either:
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.
Makes sense to cache an API call for prices, then if you don't realise you're mutating the cached object you could do this on every page load.
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).
For it to persist across refreshes you would need to do more than just mutate the object, you would need to actually write it back to a persisted location like localstorage or a cookie.
