• (nodebb)

    I completely fail to see how this qualifies as a WTF. I've worked at many places, both corporate and government, and this is simply standard practice.

  • Darren (unregistered)

    Currently living through something similar.

    Executive Team: "We need the report on the portal updated so that it emails us daily with these additional eleventy billion points of KPI data on them" Us: "Ok, but you'll not really be able to discern any real value from it - wood for the trees and all that" Exec Team: "We know what we want, just make it happen"

    • Several days later -

    Exec Team: "This report has too much data on it, it's too confusing. Simplify it" Us: "Ok, here's the new, simple version"

    • Several days later -

    Exec Team: "We're getting this report too often. Can we just put it on the portal instead, maybe with just red and green markers rather than numbers?" Us: deep sigh

  • (nodebb)

    I found this gem in production:

    public void SnarkyComment() {

  • (nodebb)

    Bummer! Some key combination sent the comment prematurely. I'll leave it to the reader to finish the body of SnarkyComment.

  • my name (unregistered) in reply to dpm

    what exactly is the standard practice? not testing, not checking if requirements are met or no one noticing that they didn't receive an email for more than a year?

  • (nodebb) in reply to my name

    Standard practice at every level, and I'm neither joking nor jesting. No code reviews, no one in management aware of how the site is supposed to work (let alone whether it's running or not), and as far as testing . . . management and the customer have both urged me to just slap it into production because they want the new functionality as soon as possible, and see QA as a waste of time. UAT is a complete rubber-stamp.

    Granted, I've also worked at good places, but you know how it usually goes or you wouldn't be reading this site.

  • (nodebb)

    I worked on a huge project where one of the project managers built 70 unique reports for executives over the course of the 16 month/$16m project time.

    The project was canceled on the last day before being announced to the world. Maybe a report was missing...

  • hasseman (unregistered)

    Tom Fishburn KPI overload: https://www.pinterest.com/pin/94434923424164656/

  • (nodebb)

    There is something deeply mess up about a society which produces such organizations. The IT stuff is tip of the iceberg of stupid in the entire experiment in maladaptive human behavior.

  • Chronomium (unregistered)

    TRWTF is people not knowing how to use filters and folders to pack away these sorts of e-mails. Having the history of reports available in an Outlook search is probably better than whatever homegrown solution is being used to search the portal.

  • Sauron (unregistered) in reply to WTFGuy

    That's absolutely true.

  • (nodebb) in reply to Chronomium

    Having the history of reports available in an Outlook search is probably better than whatever homegrown solution is being used to search the portal.

    Have you tried to use Outlook search in the last few versions of Office? It's horrible. Which is a shame, because it used to work pretty well in older versions.

  • Pabz (unregistered)

    It would be funny if the CEO had told the coder who wrote the TODO that the email wasn't important, 16 months before....

  • PICNIK (unregistered)

    We replaced an old legacy system that had 7000+ reports. On the new system, we made everyone justify the reports they were getting. We went live with 20 reports. After 5 years, it was up to 50 reports.

  • (nodebb)

    I love how users want what they want until they have it, then decide they never needed it or - worse - realize they wanted something entirely different, make you do it, and THEN realize they never needed it!

    USER: I need a report to show budgets and expenses on projects by month, rolling back a year. MANAGER says high priority! ME: <drops everything and writes report> Can you take a look at this test report? USER: But this doesn't have my department expenses ME: You said "budgets an expenses on projects". Here is the email. Your department is not a project USER: But I need that too ME: <rewrites report> Have a look-see... <crickets for a month> ME: Hey -- didja look at that report? USER: This isn't what I want ME: OK, let's talk about it <USER never mentions it again>

  • richarson (unregistered) in reply to my name

    Yes

  • Argle (unregistered) in reply to Bananafish

    Believe it or not, your description of management process is pretty much exactly how I explained recursion to my students. "Your boss tells you to write a function that takes a directory path and removes all the *.bak files in the folder. You make it and take it to your boss who then complains that you aren't processing sub-folders. You complain that you weren't told to do that. He says you were and if you weren't you should have thought of it. So, you go back to your function and look over the loop and find the point where you know you have a folder. Then you have to say 'it sure would be nice if I could call a function that would delete all the *.bak files in that folder. Aha! I'm in just such a function.' Naturally, you complete the task and return to your boss who tells you 'Forget it! We'll use rm -r.'"

  • Wayne (unregistered)

    This brings to mind an old story from my early days. Back in the '80s, I had an IT instructor who related the following story. She rewrote an org's internal financial system. Tested thoroughly. Everything went live and all was well. Then she gets a call from some department. "We're not receiving our numbers report!" 'Numbers report?' she thinks? WTF is the numbers report? She checks her documentation for something called a numbers report and there's no such thing. She goes through all of the reports that were supposed to be converted, everything was rewritten, tested, and approved.

    She goes to the department and they pull out an older 'numbers report' from a previous run. IT WAS A CORE DUMP. They had been receiving a core dump since time in memorial and by damn, they were going to continue receiving their numbers report - even if they didn't know what it was or what they could do with it.

  • Officer Johnny Holzkopf (unregistered) in reply to my name

    Yes.

  • Aussie Susan (unregistered)

    It has been "standard practice" since the 1980s at least in my experience - stop printing (in those days) and distributing a report and see how long it takes for someone to complain. If no one does immediately (i.e. however long you want to interpret that time period) then stop printing the report. Of course in those days it was a waste of paper as opposed to a waste of storage/electrons for an email - but still a waste of time all round. Susan

  • löchlein deluxe (unregistered) in reply to Bananafish

    Oh, they'll mention it again when you bill your hours against their department.

  • NotAThingThatHappens (unregistered)

    public void UnmoderateComments() { // TODO: }

  • (nodebb) in reply to dpm

    Granted, I've also worked at good places, but you know how it usually goes or you wouldn't be reading this site.

    I started reading the site while doing my Physics PhD as an entertainment, after coming across it in a list of "recommended reading for CS students".

    After starting my job on an industry project for engineering simulations software, I frequently had to suppress the urge to unprofessionally reference this website. The least of the problems is the compulsory list of nonsense named magic numbers like

    REAL(kind=doubleKind), PARAMETER :: ZERO = 0.0D0
    ! ...
    REAL(kind=doubleKind), PARAMETER :: FIVE = 5.0D0
    ! ...
    REAL(kind=doubleKind), PARAMETER :: ONETHIRD = 1.0D0/3.0D0
    

    but more the prevalence of manual testing, that makes any change to a pre-existing code-line a high-risk change, leading to awful patterns of "slap on another special case optional argument to the subroutine", and the lack of a culture of correctly understanding bad practices. I once had to point out that a module level variable is still a global variable, especially when it is public.

    Uh...

    ...

    Point was, not everyone reading this site might have first-hand experience of the WTFs yet.

  • (nodebb) in reply to NotAThingThatHappens

    public void UnmoderateComments() { // TODO: }

    I'm kind of curious how the comments are filtered for whether they need moderation. Being a registered user definitely plays a role though, since posting without registering is possible.

  • RLB (unregistered)

    I've read this story before. In fact, I've been in this story.

  • (nodebb) in reply to R3D3

    R3D3 I'm kind of curious how the comments are filtered for whether they need moderation. Being a registered user definitely plays a role though, since posting without registering is possible.

    This seems to be the algorithm (found in TheDailyWtf/Controllers/ArticlesController.cs):

    var shouldHide = containsLinks || DB.Comments_UserHasApprovedComment(ip, token) != true;
    
  • Alan (unregistered)

    The resolution is far from surprising, but, after seeing the empty-bodied "Send()" function, I would have spent one of the two minutes verifying that there had not been a code change that broke virtual function dispatch to an overriding (and functional) implementation of "Send()" in another part of the code base.

  • (nodebb) in reply to dpm

    I completely fail to see how this qualifies as a WTF. I've worked at many places, both corporate and government, and this is simply standard practice.

    And what is it that makes you think that "standard practice" and "WTF" are mutually exclusive?

  • (nodebb) in reply to Gearhead
    Comment held for moderation.
  • (nodebb)

    Comment held for moderation

    Oh right... The containsLink part...

  • CI Guy (unregistered)
    Comment held for moderation.
  • Elmar (unregistered) in reply to Aussie Susan
    Comment held for moderation.
  • Elmar (unregistered) in reply to Aussie Susan

    Ah yes, we call that "Debug by telephone"... switch something off in production and see if/how long it takes before the phone rings and someone complains about it. Average response time is usually > 1 year

  • (nodebb) in reply to Elmar

    Ah yes, we call that "Debug by telephone"... switch something off in production and see if/how long it takes before the phone rings and someone complains about it. Average response time is usually > 1 year

    Yesterday suddenly my build scripts failed for the latest master. Reason? Someone decided to change the layout of how build components are provided, without sending out information about it. As long as compiling without updating them worked, all was fine. Yesterday it started failing, because the last cached version had become incompatible.

    Point being: Just because something not working isn't noticed right away doesn't mean it isn't a critical service to someone. It just might be critical only at specific times, and become a big problem if it then suddenly isn't available on demand.

  • Shirley Williams (unregistered)
    Comment held for moderation.
  • anon (unregistered) in reply to R3D3

    Yes. Surely every company has things that only run once a quarter, once a year etc.

Leave a comment on “Check Your Email”

Log In or post as a guest

Replying to comment #:

« Return to Article