Real Time Dangers

  • Comments posted to this topic are about the item Real Time Dangers

  • In a world where the priority is bigger, better, faster we often loose the idea of correctness. If you get the wrong answer in real time is it better than the right answer an hour later? And are informed answers always the knee-jerk reactions to current snapshots?

    Far better to do a little trend analysis and at least cursory data validation and quality control. Without that analysis, one invalid steam of data can ruin a company or a days operations.

    One person may get very excited and shut down production just because the readings on one of the monitors is high, while the experienced person who has seen the trend knows that the only problem is that this is the third day and the filter on the intake of the monitor needs to be cleaned every third day and this is nothing to get excited about.

    It is better to make good decisions from good data then ....

    M.

    Not all gray hairs are Dinosaurs!

  • I've never met a computer yet that had any sort of judgement or wisdom, but we do keep trusting more and more decisions to them.

    This has good and bad aspects to it, of course. Computers also don't have political agendae, aren't racist, et al. So, that's an advantage.

    But it does dehumanize things to an extent I'm not happy with. Credit scores based on real-time data do solve some problems, but they cause huge other ones.

    I think we've gone into a form of future shock where "newer is automatically better", and shock shuts off our own judgement on the subject.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I find great humor in reading an article on Real Time computer processes that seems to need a spell check.

    What does "oif" mean anyway? :w00t:

    Seriously though, the more we rely on anything, the less we can rely on ourselves without it.

  • Hi Steve:

    This is so true that I shared the editorial with my whole IT Department, I will resume your entire article in these phrase: Fast never beat right.

    Thank You

    Rafael Colón

  • Rafael A. Colon (11/8/2011)


    Hi Steve:

    This is so true that I shared the editorial with my whole IT Department, I will resume your entire article in these phrase: Fast never beat right.

    Thank You

    Rafael Colón

    Thanks!:-P

  • Well said, Steve.

  • Great editorial, Steve. Thanks.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Sorry about the late chime-in (I'm always behind on reading the SSC daily e-mails), but this was a good editorial and sparked a couple of thoughts hopefully worth sharing:

    First, interesting thought about "overwhelming with data". This reminds me of some reading I did while researching a paper in graduate school. In an article in either Byte or Datamation (I forget which), the author wrote that the term "information overload" is actually a misnomer and what should be said in its place is "data overload". The author went on to say that data doesn't become information until it's been sorted, analyzed, and presented in a form that makes sense to whoever's on the receiving end.

    For example, one database table I regularly work with is a tracker action log that records times, user IDs, and specific actions performed for paratransit bus trips as they are scheduled, placed onto routes, and performed; and possibly rescheduled, placed onto different routes, or maybe even cancelled. That 17-million-plus-rows table is merely a mass of data. But when I write a SQL query that takes one day's worth log entries and sifts it into trips being modified under a particular set of conditions, the result is information that a manager can use to modify our agency's processes to operate more efficiently. The same thing wouldn't happen if I just took each day's worth of "raw" log entries, printed it out, and left the hard copies on the manager's desk, or (to follow the editorial's analogy more closely) if I set up a real-time feed to e-mail him each log entry as it was made. In reality, with the log entries per day generally numbering in the tens of thousands, the mail server as well as that manager would be overwhelmed with data. 😛

    My follow-up observation regarding that article is that's apparently just as true if the "whoever" is actually a software package, and it's interesting that 15+ years after I read that article, data overload is just as much of a problem as it ever was. The take-home point is that if you do any work at all with queries, turning data into information is most definitely part of your job description.

    Second thought, somewhat on the lighter side: the line about computers giving us the power to make mistakes faster than ever before reminds me of the old saw about the farmer having to work ten times harder than the city man to lose his money. :hehe:

    Anyway, interesting and well-said editorial. Thanks for sharing and for the trip down Memory Lane!

  • Geoffrey Wrigg (11/21/2011)


    Anyway, interesting and well-said editorial. Thanks for sharing and for the trip down Memory Lane!

    Thanks, and glad you enjoyed it.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply