Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty five thousand dollars of funny money

rachelbythebay.com

Post reply on HN
Print view View original

81–90 of 175 posts

Re: Twenty five thousand dollars of funny money

#81

Post by macintux »

ThePadawan wrote: post #45
jks wrote: post #26

Earlier quoted context omitted.

Way back in the 1990s I worked in a place where we had to use Ada and follow a strict style guide. The guide prohibited using raw numeric types (such as "unsigned int" or "double" in C-like languages) and required creating a new type ( https://en.wikibooks.org/wiki/Ada_Programming/Type_System#De... ) for each different quantity, such as temperature or speed. Then you couldn't assign a speed value to a temperature var…

In the mid-2010s I worked at a company that switched from using raw ints to refer to database rows to using (in C# terms) "Id ". Across the entire codebase, we discovered an entire class of bugs that only never cause any issues because all the important rows in all the important tables had Id 1 (e.g. Currency 1 was USD and Country 1 was USA) - so in a few places where the ints got mixed up, the correct row was still…

Something I learned long ago, but occasionally disregard to my peril: if you see something that looks like a bug, but the code/system still works, stop and figure out why it works.

It's very easy to mentally shrug and move on, but more often than not it comes back to bite you; maybe it's a code path that's rarely triggered, e.g.

Re: Twenty five thousand dollars of funny money

#82

Post by adamsb6 »

richard_mcp wrote: post #2

I'm confused how this was able to give out money before the new code was submitted to production. The author claims that both she and her coworker tested it before the code was submitted and they ended up with the extra $25k. Was this code only executed on the front end? Were there no checks in the backend to prevent employees from just pulling out whatever money they wanted?

The way that things work at this particular company is that you typically test changes in this codebase on your dev machine, but usually the dev machine talks to a prod database.

The prod database is too large to practically have a second copy sitting around for testing. Also, if you tested on some pristine small test database you're going to end up missing bugs that would only manifest with actual prod data.

Re: Twenty five thousand dollars of funny money

#84

Post by scatters »

denton-scratch wrote: post #34
WrtCdEvrydy wrote: post #6

I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.

You don't need "strict typing" to handle money; in the old (COBOL) days, we used BCD to represent monetary amounts with arbitrary precision. When they took away BCD, we were stuck, if we wanted to build a system that could represent a large sum correctly in both dollars and yen. COBOL was pretty good for dealing with money.

You still don't know whether something is dollars or cents. Some things are conventionally priced in dollars, others in cents, and your customers are going to be very unhappy if they have to enter or read the price in the "wrong" unit.

Re: Twenty five thousand dollars of funny money

#86

Post by cratermoon »

There are several things happening here worth breaking down.

The first is what I've seen called a "gettier"[1]. The idea of "justified true belief" which ends up being true, but not for the reason you thought it was true. That's the case of the first of the bug fixes: She'd exposed the problem with the first change, but it wasn't really the problem.

The second item of note is that one paper found 92% of catastrophic system failures come from buggy error-handling code.[2] Arguably this doesn't count as catastrophic, but $25K adds up.

The third and final item is the failure relating to the use of a primitive, number' instead of a domain-relevant type, like Money, Dollars, or Pennies. This concept came up as Value Object three days ago[3], which Ward Cunningham's CHECKS Pattern Language of Information Integrity, published in 1994, called Whole Value[4]. I've seen (and, as a young code, written) programs that are full of strings for everything, because that's how the they are represented to users and passed over (some kinds of) network services. This "stringly typed" code infests a project I'm currently engaged with, simply because the back end depends on a bunch of REST/JSON apis and never bothers to deserialize them, but passes them throughout large parts of the code completely unrelated to the api calls.

1 https://jsomers.net/blog/gettiers

2 https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o...

3 https://news.ycombinator.com/item?id=33792874

4 https://c2.com/ppr/checks.html#1

Re: Twenty five thousand dollars of funny money

#87

Post by lxe »

WrtCdEvrydy wrote: post #6

I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.

Strict types have little to do with this. Unless your type system validates bounds , this sort of things happens regardless of types.

Re: Twenty five thousand dollars of funny money

#88

Post by mbell »

jacobn wrote: post #41

Had exactly that bug in production, was using ruby on rails & active merchant, and some version change in ActiveMerchant switched from cents to dollars for one of the integrations. Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out. Shortly thereafter I get an anxious customer call that we'd charged their debit card $2500.00 instead of $25.00 a…

> Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out.

This is why I'm pretty dogmatic about variable comparison in tests.

This is dangerous and stuff like this has caused a lot bugs to slide though in my experience (and maybe ops):

    expect(account1.balance).to eq account2.balance
This is safe and specifc:

    expect(account1.balance).to eq 2500
    expect(account2.balance).to eq 2500
Unfortunately I've run into a lot of folks that take major issue with the later because of 'magic numbers' or some similar argument. In tests I want the values being checked to be be as specific as possible.

Re: Twenty five thousand dollars of funny money

#89

Post by stavros »

xg15 wrote: post #75
snotrockets wrote: post #50

Earlier quoted context omitted.

I think you’re confusing expressiveness of types with static/dynamic typing (the latter are also typed!) An expressive type system would allow you to define both a cent and dollar types, s.t. assignments of those types to each other without conversion would fail. In a way, it is a way to have the computer validate apps Hungarian rather than trusting the programmer (well, it’s more, but for this argument). Go’s type s…

Ah, my bad there. That was what I meant with subtypes, but you're right, things have moved further there already. Sorry for the misinfo!

Yeah, defining "dollars" and "cents" (and over units) types are actually a really good solution for this, it means that you can never pass a value of one unit when the function expects another.

Re: Twenty five thousand dollars of funny money

#90

Post by cratermoon »

Eleison23 wrote: post #52
jacobn wrote: post #41

Had exactly that bug in production, was using ruby on rails & active merchant, and some version change in ActiveMerchant switched from cents to dollars for one of the integrations. Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out. Shortly thereafter I get an anxious customer call that we'd charged their debit card $2500.00 instead of $25.00 a…

>internal video camera pulling back poltergeist-style That cinematic technique is called a "dolly zoom" and it's totally dramatic, if used correctly!

Alfred Hitchcock famously first used it in his movie Vertigo, after one of his camera operators, Irmin Roberts, came up with the effect.
Post reply on HN