I swear to god, I'm going to track down the dipshit who just made my day hilariously painful.

So here I am, finishing up this project that's been going on for what feels like an eternity, when I get an email "why doesn't order X show up in this other system?".

I mean, it's a common thing they can take 15 minutes to push across, so the usual quick glance and what do you know, it's just sitting there as if it's waiting to be pushed through, than an hour later... it's still there, so I start digging, maybe a data issue, nope looks all good, customer details, payment details, products...

just another order, jump on the logs and all looks fi......... wait.... why does this postcode have 3 digits and not 4 , Australia has 4 digit postal codes fyi, looks at order again, 3 digits, look at log, 3....hold on why's it only 3 digits, checks code, handled as string... ok..... where the fuck would it drop a digit.... frontend requires 4 digits, validation requires 4 digits... how the fuck did you get 3 digits in... I can't see anything anywhere that logically makes sense for this🤔

Drops address into google and it's a postcode starting with 0.

Jumps on DB and the fucker is an int in the postcode table. For all you playing at home 0123 <> 123

I don't know if I should feel bad, or impressed, it's been 7 years since this table was created, and 7 years before someone managed to live in one of these parts of the country with a leading 0.

QA didn't spot this years ago,
No one tested this exact scenario,
The damn thing isn't even documented as a required delivery area, but here we are!

Kudos good sir, you broke it! 🤜 🤛
You sir may get your order now!

  • 9
    Shit, that doesn't even work outside your locality. My flat in glasgow is in post code zone G2.
  • 5
    @SortOfTested international isn't a thing for this particular one, luckily.
  • 2
    That's like a daily occurrence for our sad account creation system. The thing is made of glass.
  • 3
    Be glad it was only a cut-off leading zero. Fun begins when numeric strings with leading zero are interpreted as octal.
  • 1
    Pfft at my company they patched it with padding zeros. Applicatively.
  • 1
    After reading your rant, this website comes to mind... https://mjt.me.uk/posts/...
  • 7
    Yeah you need a thick skin for this kind of shit.

    Every DB I've touched in the last 20 years had at least one unfortunately chosen type. A Postgres DB with Phone numbers as integers. IBAN as a fixed-length varchar but without trimming spaces in validation. Gender as boolean true/false (apart from the non-binary debate, it didn't even document what "gender == false" meant).

    Zipcodes as... a fucking MySQL enum, in an attempt to exclude non-existent areas.

    I feel like all programming languages and databases need native types for these things. Not even an well-supported library, just built-in types, done well. Fully validated upon conversion. HTML should have an IBAN field which only allows valid IBANs. JSON? Here, have an IBAN type. SQL? You get an IBAN column!

    Also ISO-8601 time, valid zipcode formats for all locales, E.164-formatted phone numbers, lat/long, Binary geo shapes, validated dickpicks, etc, I dunno.

    Strongly Type All The Things.
  • 7
    Actually a MySQL column which can only store validated dickpicks would be fun.

    "Please check the form before resubmitting, you forgot to upload a penis, or the size is too large. Please submit a dick of appropriate size"

    "But why does this company need my penis"

    "For authentication and marketing purposes. GDPR doesn't explicitly define penis pics as sensitive personal nor biometric data, so we might sell your schlong to third parties"
  • 1
  • 2
    @Root Validation failed, no butts allowed.
  • 0
    Fucking dipshit. You’re right, as always.
Add Comment