Live data from Hacker News

Twenty five thousand dollars of funny money

rachelbythebay.com

41–50 of 175 posts

Re: Twenty five thousand dollars of funny money

#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 and they'd gotten an overdraft notice. At first I was incredulous ("how is that even possible!?"), then I remembered that we'd just version bumped ActiveMerchant.

My endocrine response as I realized what must have happened was amazing to experience - the sinking feeling in my gut, hairs standing up, sweaty palms, dread, pupils dilating, and my internal video camera pulling back poltergeist-style in a brief out-of-body experience.

Fun times. Live and learn.

Re: Twenty five thousand dollars of funny money

#42
post #25

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.

I'm also in the camp that believes that functions or methods that take more than 2-3 (positional) arguments should really take a structure with named keys to avoid this. Humans are bad at lists. Seeing functions with 5-6 positional arguments makes my skin crawl even if they have strong types.

[deleted]

Re: Twenty five thousand dollars of funny money

#44

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.

Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need This matches my experience. Obviously actual strict typing has its benefits, but as far as developer ergonomics are concerned, IME you can get about 95% of the benefits just by following a convention of including unit names in identifier names. It's easy to see why this Ruby code might fail…

Easy!

    # not happening unless developer consumes a large number
    # of drugs
    distance_miles = 42
    launch_rocket(distance_km: distance_miles*1.6)
Aaaand we're off by 0.3924km. Enough to fit 4 football fields with a few meters left over. Oopsies

Units are hard. Never under-estimate the ability of programmers to think they're converting but get it slightly wrong.

Re: Twenty five thousand dollars of funny money

#45
post #26

I think I like the duck typing in TypeScript more than I dislike it. But I still wish I could say “this function accepts a type called RobotName. It’s a string, but so is RobotUuid, and we don’t want that. So only accept, strictly, objects typed as RobotName.”

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 accidentally looked up in the wrong table).

Re: Twenty five thousand dollars of funny money

#46

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?

As I understand, the frontend and backend code run in a development environment but the funds available were stored in a production database.

Re: Twenty five thousand dollars of funny money

#47
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…

how did that work out in the end?

Re: Twenty five thousand dollars of funny money

#48

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.

This bug could easily happen in a typed language though.

  function deduct(int cents) { ... }

  int dollars = ...
  deduct(dollars);
You need something like (Apps) Hungarian notation [1] as a minimum - or even better, subtypes of primitives like in Go to represent units in a typesafe way.

[1] https://en.m.wikipedia.org/wiki/Hungarian_notation

Re: Twenty five thousand dollars of funny money

#49
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…

Oh wow. Was there a “stomach sank to the floor” sudden feeling upon discovery?

Re: Twenty five thousand dollars of funny money

#50
post #48

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.

This bug could easily happen in a typed language though. function deduct(int cents) { ... } int dollars = ... deduct(dollars); You need something like (Apps) Hungarian notation [1] as a minimum - or even better, subtypes of primitives like in Go to represent units in a typesafe way. [1] https://en.m.wikipedia.org/wiki/Hungarian_notation

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 system is anachronistic, compared to what modern language provides (but then, all of go is anachronistic on purpose. The usefulness of this purpose not to be discussed here).

Post reply on HN