Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday July 17 2017, @03:27PM   Printer-friendly
from the swear-on-a-stack-of-K&Rs dept.

At The Guardian, Cathy O'Neil writes about why algorithms can be wrong. She classifies the reasons into four categories on a spectrum ranging from unintential errors to outright malfeasance. As algorithms now make a large portion of the decisions affecting our lives, scrutiny is ever more important and she provides multiple examples in each category of their impact.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by meustrus on Tuesday July 18 2017, @02:56PM

    by meustrus (4961) on Tuesday July 18 2017, @02:56PM (#540954)

    the automated tests can still give a result of "passes" after a code change by coincidence when it should actually fail.

    Sure, if your tests are too low-level. But I'm advocating for system-level acceptance tests, not unit tests. The problem with those is far more often that they tend to give too many false negatives, due to brittle test frameworks and the difficulty in getting a machine to simulate human interactions with the product interface. And tests can never cover the interface itself, since organization, positioning, and styling are all visual elements affected by human psychology more than anything else. UI/UX testing and verification is another thing that will need to be done manually. But with appropriate acceptance tests, you can still be sure that the interface performs as it was designed to.

    An important fact that automated test evangelists leave out is the maintenance cost of those tests which must he updated and debugged just like the rest of the code. If you automate TOO much, you lose productivity to excessive test code work instead of the system you are getting paid to deliver.

    And if your tests are that complicated and difficult to maintain, that's because making changes to your system has unpredictable consequences. That's its own problem that needs something more drastic than testing to fix. If you make a change and half your tests break, you might be annoyed that you have to go fix a bunch of tests. But I'd be more concerned that without those tests, we'd all be spending the next year discovering bugs and losing productivity to fixing them as they come up as "must fix NOW". Not only that, but you are potentially losing business value, be it customer retention, marketing success, legal exposure, or actual ability to make sales. You might not feel that pain, but those things affect the ability of the business itself to function and threaten your job and everyone else's. The tests didn't make you lose productivity. They just made you deal with your chaos monkey of a system before it caused real problems instead of letting those problems simmer until they either demand your nights and weekends to fix or destroy the business.

    --
    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2