I worked for a large retailer on their iPhone app and our test environments were terribly slow so we tended to do most of our development against production.
This retailer is pretty old and had issued their own credit cards that didn't have any sort of checksum validation. This made making test orders easy because any sequence of numbers for that credit card type would let the "checkout" call succeed, and then the order wouldn't actually be fulfilled because the card would turn out to be invalid.
We usually used a sequential list of numbers because that was so fast to type and we used a made up Address in Tok Alaska. The state picker had Alaska first and Tok (also Eek) were the shortest city names we could find in Alaska.
One day someone took a look at one of our test account's order histories and noticed that there was a tracking link for the order. That "fake" credit card number turned out to be quite real. We shipped a dress to Alaska, which was then returned to sender because the address (1 A St) didn't exist.
We were much more careful after that but as far as I know, nobody ever complained and we never heard about it from anyone outside our team.
This reminds me of the bug in the stealing script in Office Space. The script was supposed to steal fractions of a cent, but, instead, it was stealing dollars.
In the end, it turned out OK. The joint burned down, and Milton ended up on a beach, sans Swingline.
Are all these articles this "lightweight" and short on details and sound like a made up coding morality tale?
Just the style here throws me.
I have briefed Register journalists 100+ times and this is is absolutely their editorial style. If you go technical, they do their best to translate what you've said into analogies that mid-market IT managers will understand. It was embarassing because my fellow engineers would often read an article and be alarmed that I may not understand our technology because of this.
The issue is that you can't not brief The Register because they're insanely influential with customers in certain tech markets. All said, they're usually fun to meet with and many of their writers are real characters.
They also Know Their Stuff; even if they have a "redtop" style.
i mean the register is kinda more of a tabloid than anything, it's real-ish news but with a loose and snarky editorial style, so... it's pretty on-brand.
El Reg is basically The Onion but targeted at enterprise IT. That said, for things in that domain -- like SAP or Oracle, but especially SAP -- they really do know their stuff and offer frequently insightful content.
In the early wild-west days of ecommerce a friend working as a tester at a well known British supermarket discovered that the backend card-validation logic on their payment form was essentially "return true" ... good thing the volumes were miniscule I guess?
We know it works because all the happy path tests pass, and all the sad path tests fail.
I worked at a very well known news company. Their auth proxy layer was set to “fail open” for a period of time if there was any issue detected in the auth backend (i.e. just return ok and a new cookie for 30 seconds). When I checked the logs that system was in a fail-open state over 50% of the time.
100% test coverage
I wrote a faxing queue because our fax server at the time was horrible at converting pdf's to fax appropriate tiff's. I didn't think to block an area code that was 911. The cops showed up when a user accidentally fat fingered 911 as an area code.
Long story short, as a junior programmer I did not fully appreciate the difference between credit and debit and ended up putting a bunch of money on customer credit cards instead of deducting it. And yes the app somehow passed our payment processor's validation exercises. Total damage was maybe $10k, but I think we managed to roll most of it back.
This reads a bit like an article from "the daily wtf", I used to frequent that one often [0].
I still have their mug!
(Which my child consistently gives me shit for. "Dad, why we we have a cup with the F-word on it!?")
Sounds like your kid deserves a shoutout on dailystfu.com
In case it needs to be said, I'm kidding.
This belongs to the class of bugs/"features" that one could refer to as "Superman 3" issues.
Or, Office Space issues.
(And before anybody says it, yes I know they refer to Superman 3 in Office Space)
Reminds me of a similar bug in a payment processing system the company I worked for used. Long story short, overflow in Java numerical types (counting milliseconds for durations in weeks...) caused the system to go haywire and charge customers 1000x the normal amount...
It turned out very profitable for the company though. Stonewalling customers and refusing charge backs is too easy. Not picking up the phone is a good business strategy.
> refusing charge backs is too easy
That doesn't sound right...? Credit/debit card chargebacks are handled by the bank. If the merchant doesn't pick up the phone, the bank will take the money from the merchant and return it to the customer.
https://www.usatoday.com/money/blueprint/credit-cards/credit...
Were you using a different payment system with fewer consumer protections than credit/debit cards?
This is not a true story because as a merchant you cannot "refuse chargebacks". In fact too many chargebacks will result in a loss of your merchant account. You should really stop making things up.
I read this person as using “chargeback” to mean refund.
However, merchants do have an opportunity to respond to a chargeback request. Providing plausible evidence that the request is in bad faith will often result in the bank not performing an actual chargeback.
Sorry Sherlock, I meant charge back as in "refunds" not credit card disputes. Also, merry Christmas.
I recommend to edit your post with an "update" so others don't have to dig to find this clarifying comment
damn
Stories like this are why I'm happy that the company is understanding that OPs, stability and control vs Dev, Fast changes and Agility aren't binary, polar opposites, but more of a throttle.
Like, for a lot of state free application logic, or even read-only frontend stuff, just do. A roll-back or a roll-forward is easier than heavy-weight procedure.
But if payment, customer authentication, migrations of large databases comes in... Suddenly these ops-guys with their careful rollout, validation functionality, dry-runs and ring rollouts are pretty good at keeping the day boring.
Office Space just keeps replaying in my head. All he needed was a timely fire to get away with it.
It's unstated but are we to understand that he set up the test to send money to a test account which was his own personal account?
Not unheard of, unfortunately.
Funny enough, in a fintech I worked for, developers and QAs actually used their own personal credit cards and bank accounts for testing.
Interestingly, they also needed to test ApplePay, but the laptops didn't allow for adding their personal iCloud accounts. So someone in the development team got the "admin" password and distributed among devs and QA team, and they all had unprotected laptops. They probably still do.
I wonder if NOT providing a separate, exclusive account/card/sim etc to a developer is a common trope in fintech. I avoided linking my personal things like hell, and they avoided giving me a damn immutable plastic that would work/get paid for more than a few days. So much friction just because something stopped working or had to get back into oven and they had no replacement at hand. I even had to maintain a separate table for tracking personal balance-replenishing expenses cause no one’s gonna do it immediately. The same people who were chirping about the importance of experimenting, prototyping and not minding any expenses under $$$ or something all day.
It's a ouroboros of bureaucracy getting in the way of security and security causing the bureaucracy itself.
Not to defend that, but the question is how quickly would they be able to set that dev up with a test-bank account? In the orgs I know this would probably take a month or so.
So taking your own account during early development can make sense. Leaving it in is probably a bad idea tho.
Its my opinion, but you shouldn’t need a bank account or even internet connection to work on the code at all. Instead its better to mock it out in development.
I work somewhere where it can take four layers of management to get a service or test account. No one has time for that shit.
I always liked this clause from the Underhanded C Contest:
"The Underhanded C Contest was a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake even if discovered."
Ship fast they say, but do not ship that much faster.
This read to me as if someone asked a LLM to create a facebook urban legend about a bad programmer and prompted it with a couple bullet points.
If it contained the words “you’ll never believe what happened next…” they would be completely at-home.
I got the same vibe. I hate that I get those vibes wrong sometimes, but this story is so devoid of detail and life that it seems like the outline of a more realistic story.
This is a cute little story with some technical merit - the brief description of the three bugs is kind of interesting.
To me it read like someone saw a Reddit post and decided to write a story. Funny so many folks got similar vibes.
Dear Reg, it finally happened to me ...
What’s that boast again,
“move fast and break things” …
Breaking things isn't ideal, but it's not the worst. What's truly problematic is when everything appears to be functioning perfectly, while underlying issues go unnoticed—exactly the situation in this story.