• LZ79LRU (unregistered)

    And I bet you he didn't get so much as a pat on the back for his effort.

  • Hanzito (unregistered) in reply to LZ79LRU

    Probably the only thing he got was weekly inquiries why it took so long to make such a simple change. "Are you sure you're up for the job?" Followed by a B- evaluation, because his 1-point XS ticket took 3 months.

  • (nodebb)

    What stuns me is that Jeff was stunned by the corporation's attitude --- it looks extremely typical to me.

  • erichamion (unregistered)

    Although UNION ALL is certainly appropriate here, the issue wouldn't have occurred if each of the UNIONed queries just had a second column with a unique description. What's the point of a raw list of numbers, if there's no indication of what each number means?

  • (author) in reply to erichamion

    The submission didn't say, but my assumption is that this entire thing was a subquery in a larger query, so the context comes from that larger query. Or, since it was on a report, it may have just driven a single field, in which case, the context was on the report.

  • (nodebb)

    I expected something like "Because the report was so old, it COULDN'T be wrong, and the executives fired all the sales team anyway. It was months later they realized that the report was, in fact, wrong, but by then the damage had been done."

  • erichamion (unregistered) in reply to Remy Porter

    Oh, I didn't notice the top line, SELECT SUM(subtotal) FROM <all the unioned queries, which each performs a sum itself>. So yeah, it does all collapse down into one row at the end.

  • (nodebb)

    Nothing special honestly. I had once a client long time ago that lost every year the income of a complete hour in their books because their DB didn't use UTC but some local time zone and daylight saving erased one hour every year while overwriting another one. Everyone know in the IT department, nobody in the business section wanted to even touch the topic for not "burning bridges", whatever that means in this context. My guess was that they were afraid of calling out high levels of mid management over their decade old mistake that developers had to implement after protest anyway because reasons.

  • (nodebb) in reply to erichamion

    Although UNION ALL is certainly appropriate here, the issue wouldn't have occurred if each of the UNIONed queries just had a second column with a unique description. What's the point of a raw list of numbers, if there's no indication of what each number means?

    I've worked in places where "The Report" is just a single number. No label. No description. Not even a report title. Just a number. And it means ... EVERYTHING! We had two of those: 1- Total Billed; 2- Total payments received. No detail, no "by client" breakdown. Nuttin.

    Nothing "wrong" with that, if everyone knows what the number means. Nothing "right" with it, either.

  • AussieSusan (unregistered)

    Somewhat related; several decades ago I was tasked with leading a project to migrate from one computer system (and database) to another (the computer/database that my company made). All went well with the data migration until we ran a comparison report (one that went to the state parliament and reported on the activity of the organisation) and there were significant differences. We finally tracked it down to the fact that our report counted the actual records in the database, whereas the old system started with a number and then added 1 when a new item was added and subtracted 1 when it was deleted - except in some circumstances when the subtraction was skipped! Our report was therefore accurate. The client then had the audacity to ask if I could change the report so that it reflected the old numbers and over the next year gradually changed to the correct ones. Needless to say this was rejected and the client had to front Parliament to say why all of their previous reports had been wrong.

  • (nodebb)

    which meant he was called upon to manually run a "test" version of the report containing the fix every time a C-suite executive wanted one, until the end of the following quarter, when he could finally integrate the fix.

    Ahh, job security at its finest.

  • Michael R (unregistered)

    I was working for an investment bank back in the mid 90s developing a trading system in Microsoft Access 2.0. We were way ahead of the competition with that. The risk people asked for a monthly printed report on the first day of the month for the previous month. So we created the report, and printed a whole tree every month. After two years we (no the risk people) figured out the numbers were wrong. No one ever complained. This taught me a valuable lesson.

  • gnasher729 (unregistered)

    Years ago someone calculated the average sick leave time for various accidents. Then one year someone had a truthfully horrific accident and stayed 11 months in hospital. That’s how fail it was. Next year someone had the same accident and stayed in hospital for seven days. That just couldn’t be right.

    It turned out it was the same person. In hospital from Feb 1st to Jan 8th, counted in two years. It turned out that anybody in hospital from Dec 31st to Jan 1st was counted as two accidents, with the sverage sick leave time systematically too small.

  • Loren Pechtel (unregistered)

    Code like this can't be tested--you can verify operation on your test data but you have no way to see if there's an error with certain values. And code that can't be tested has bugs. Period.

  • Chris O (unregistered) in reply to Bananafish

    Oh yeah, those are usually business run the the old boys, the one number, big button companies. One of my earlier gigs (circa 1996) was working at one of those companies, the IT director that hired me didn't understand that culture so he kept trying to force changes. The more he insisted, the more pushback he got, until he was either let go, or left, I'm still not sure what the circumstances were exactly. But, the guy who took his place was another employee (John) who had some technical knowledge, but understood the culture and mindset of the 'top floor guys'. He explained the 'Big Button' mindset to me and it's amazing how often I've come across that since.

  • markm (unregistered) in reply to gnasher729

    How many accidents does this company have, that they had to write code to count them rather than doing a manual report? Not that a manual report could not have made the same mistake. How many hospitalized in 2023? One. How many hospitalized in 2024? One. How many hospitalized in 2023-2024? One.

Leave a comment on “The Sales Target”

Log In or post as a guest

Replying to comment #:

« Return to Article