We Can Figure Out What It's Supposed To Do Later



  • My boss+1 decided that he needs to be able to keep an eye on the real-time load of 300+ processes that are running on a cluster. To this end, he has me create this reporting mechanism that feeds a third party system that shows green, yellow or red status in a heat-map sort of display. No specs. No list of what he wants to monitor. Just show him what's going on. In his words: "just build it; we can figure out what it should do later"

    So, I'm an architect/general contractor, and I'm to build him a house, and he'll tell me the style, number of floors and bedrooms after construction is completed? Niiiiice!

    Pushing this guy for specs is futile, so I put together a list of all stats that could be used to guage system performance that could be collected and updated in real time, the tasks that would collect them, and the mechanism to display them. The following conversation ensued over the next 2 months:

    B+1: Oh, that's not what I had in mind - change it!
    Me:  To what?
    B+1: I'm not sure what I want to see
    Me:  I'm not The Great Carnac; rather than having me guess at what you might be envisioning, don't you think it might be more appropriate to wait until you can describe what you want to see?

    This goes back and forth a few rounds. Based upon some guesswork, I figure out what he *meant*, and give him what he needs so that it looks like what he was imagining. Once he can finally look at readings:

    B+1: Can you tweak this alert-threshold lower?
    Me:  That's a standard deviation that ranges between 0 and 1; it's informational only; there's no alarm threshold! I used MAX_INT-1 and MAX_INT to indicate: no-alarm (yellow and red respectively)
    B+1: But you can set a threshold so you shouldn't use MAXINT-1 and MAX_INT
    Me:  What threshold would you like to see?
    B+1: 999 and 1000 seem closer to realistic thresholds...
    Me:  But...
    B+1: Can you set this other threshold higher so we don't see the alarms every day?
    Me:  The alarm is a legit error; why not just fix the upstream problem instead?
    B+1: Because the other group is busy and you can just make the alert go away by tweaking this number
    Me:  But that will just mask the problem...
    B+1: I don't care; I want this report completely green!

    *sigh*

     



  • @snoofle said:

    B+1: I don't care; I want this report completely green!

    <html><body style="background-color: green">&nbsp;</body></html>

    There, I just made it a web app for him.



  • The let-me-tweak-some-settings-to-hide-the-errors request is a common one.  It seems to be especially pernicious when the report is being used for a "metric" - even if it doesn't actually affect bonuses or anything.

    My de facto solution to this is now to have two reports - one report that shows the fudged data, and a second report that shows exactly what is being fudged and who fudged it.



  •  Dear Snoofle,

    Please build me an application where myself and all of the internet users and share and send media, communicate etc with each other ... a bit like facebook/hotmail/google/salesforce/sap/photoshop/firefox/vim.

    Please build it to the follow specification:

    1. Looks Cool and to my colour scheme

    2. Better then face book or any other popular web site

    3. Makes the organisation lots of money.

    Thankyou i look forward to seeing this tomorrow

     

    Regards

    Boss+1



  • @bstorer said:

    @snoofle said:

    B+1: I don't care; I want this report completely green!

    <html><body style="background-color: green">&nbsp;</body></html>

    There, I just made it a web app for him.

    I got a new theme for my cell phone, with a "neon clock" as background. It looked very nice, but the time seemed to be just a little off.

    Long story short, it was just an animated GIF, showing the seconds cycling around. It was pure coincidence that the pictured hour and minute were close to the current time.



  • @Aaron said:

    The let-me-tweak-some-settings-to-hide-the-errors request is a common one.  It seems to be especially pernicious when the report is being used for a "metric" - even if it doesn't actually affect bonuses or anything.

    My de facto solution to this is now to have two reports - one report that shows the fudged data, and a second report that shows exactly what is being fudged and who fudged it.

    I know that one.  Sadly, I can do you one better: I've had 3 versions of a report.  The real report, for and by me.  The original report that was written by Shitty Developer and everyone takes as gospel even though it is completely wrong.  Finally, a "fudged" report that tries to bridge the massive chasm between the real report and the original report.  This is used so that customers or senior management or Shitty Developer don't realize how badly the original report was fucked.

     

    It depresses me to know that I have literally spent hundreds of hours of my career fudging numbers in a database or tweaking code so that it generates a report that is just skewed enough to be believable.  Come to think of it, I may have told this story here before.  Regardless, the fudged numbers were never used for anything we directly billed for, so I suppose it was quasi-ethical.  Mostly just stuff like page view stats; we didn't want a customer regularly having ~14 million hits per month suddenly dropping to 70k when the new report was put in place so I'd be tasked with faking data for several months so that the drop appeared more gradual and "natural".

     

    Sometimes, when people ask me for the proudest moment in my career, I consider telling them that story.  Then I realize I have far more demeaning and idiotic stories to relate.



  • @Aaron "used for a metric"

    That's precisely what this was - hundreds and hundreds of pointless metrics on every dinky internal aspect of the system, when all he really wanted was "Do we have enough space left in the database for the next few weeks of data?"

     



  • I'm not sure what's worse:

    "We'll work out what it's supposed to do later"

    or

    "A delivered product with a well defined (and agreed on) spec, but a customer seeing the end result and then saying "Nope, thats not what I actually want"

    Though either way I don't care as I bill by the hour.



  •  You clearly didn't build this report properly. This is how it's done:

     <?php

     echo "Everything's shiny, Cap'n, not to fret";

    ?>



  • @DOA said:

     You clearly didn't build this report properly. This is how it's done:

     <?php

     echo "Everything's shiny, Cap'n, not to fret";

    ?>

     

    That's the plaintext version of bstorer's rich graphical implementation.



  • @dhromed said:

    That's the plaintext version of bstorer's rich graphical implementation.
    Yeah, but does bstorer's app work for colorblind people? I think not!

    This is elementary accessibility stuff people, come on!



  • At leat now you have clear requirements.

    The report should be completely green.



  • @DOA said:

    @dhromed said:

    That's the plaintext version of bstorer's rich graphical implementation.
    Yeah, but does bstorer's app work for colorblind people? I think not!

    This is elementary accessibility stuff people, come on!

    It's not my fault the requirements weren't ADA-compliant.


  • @Aaron said:

    My de facto solution to this is now to have two reports - one report that shows the fudged data, and a second report that shows exactly what is being fudged and who fudged it.

    Ahh yes, the Enron solution. Nicely done :)


Log in to reply