Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming Science

Code Quality Predicted Using Biometrics (vice.com) 122

An anonymous reader writes: Swiss researchers are unveiling "a not at all sinister-sounding system capable of predicting the quality of code produced by developers based on their biometric data," according to Motherboard. "By looking at the programmer as they program, rather than the code after the programmer is done writing it, the system described by the Zurich researchers finds code quality issues as the code is being produced... By using heart rate information, for example, they were able to quantify the difficulty a given programmer had in producing a piece of software. This information could then be used to identify likely sections of bad code..."

In a paper to be presented at an Austin engineering conference this week, the researchers write that "Delaying software quality concerns, such as defects or poor understandability of the code, increases the cost of fixing them," calling their system an improvement over code reviews, even automated ones. "Biometrics helped to automatically detect 50 percent of the bugs found in code reviews and outperformed traditional metrics in predicting all quality concerns found in code reviews."

On the other hand, Motherboard likened the stress level for programmers to "a coding interview that never ends where you also happen to be naked. "
This discussion has been archived. No new comments can be posted.

Code Quality Predicted Using Biometrics

Comments Filter:
  • by Anonymous Coward

    So the easy parts will have cleaner code than the hard parts? Uh...duh?

    • by Anonymous Coward

      Someone who's unfamiliar with the code might not be able to tell at a glance which parts are easy and which parts are hard, especially in a large, complex CR.

    • Re:This is stupid (Score:4, Insightful)

      by Wycliffe ( 116160 ) on Sunday May 22, 2016 @10:50PM (#52162555) Homepage

      So the easy parts will have cleaner code than the hard parts? Uh...duh?

      Yes, but the point is that they are automatically detecting which parts are the easy parts so that you can focus your time doing code review on the parts that the developer struggled on and therefore are more likely to have bugs. You could also use this information to assign "too difficult" tasks to a different more experienced developer. It's interesting but I can't imagine anyone wanting to wear biometrics all day every day.

      • developer struggled on and therefore are more likely to have bugs

        Not really. More likely that the developer thinks there might be bugs here, and might consider this part of code to be treated with care from now on. But more likely to have bugs? I think there is an equal, if not bigger, contributor of bugs from developer thinking something to be very simple whereas it turns out to be not-so-simple. This comes from lack of domain knowledge, lack of imagination/knowledge of all usage scenarios, unawareness of industry standards in this type of code etc.

        Though it might work

      • I think Fitbit, and the exploding wearable's market in general would disagree with you there.
      • Re:This is stupid (Score:4, Insightful)

        by JoeMerchant ( 803320 ) on Monday May 23, 2016 @08:24AM (#52164001)

        The "whoosh" for me in this is that I develop the solutions to the hardest parts of my software problems when I am far far away from the keyboard. Sitting down and grinding out code is one thing, but elegant solutions to tough problems rarely come while staring at the screen.

    • Re:This is stupid (Score:5, Interesting)

      by Anonymous Coward on Monday May 23, 2016 @01:28AM (#52162899)

      The method doesn't measure if the code is easy or difficult, it measures if the programmer was over or under-qualified to write the particular code the programmer attempts to write.
      If the coder struggled but the result turned out great then the method will still flag the code to be likely to be bad.
      The method will also completely miss buggy code caused by the programmer not realizing that the problem is tricky and going for a way too simple solution.
      It takes no effort to not add input validation. A biometric test won't help you out there.

      I wonder if this method performs better than keeping track on how long time a particular code segment have been shown on screen. (Possibly compared to characters written/edits made?)
      Spending too much time on a function could indicate that something tricky is attempted to be made, but also that effort might have been spent trying to fix the code.
      Spending significantly less than average time looking at a function could indicate that bugs have been looked over.

      In general I don't like using biometrics since it is hard to deal with noise caused by external factors. If the programmer has medical issues or is going through personal problems this will likely impact the result. Some code might appear to be tricky while the reality is that a wasp had entered the office when it was written.

      • by JaredOfEuropa ( 526365 ) on Monday May 23, 2016 @05:00AM (#52163341) Journal
        Worse: some PHB will mix up cause and effect, and spike the coffee machines on the coder's floor with anti-anxiety pills and Metoprolol, in an effort to reduce stress and heart rates thus improving software quality.
      • The method doesn't measure if the code is easy or difficult, it measures if the programmer was over or under-qualified to write the particular code the programmer attempts to write. If the coder struggled but the result turned out great then the method will still flag the code to be likely to be bad.

        While you have pointed out the downsides to this type of metrics, the term "under-qualified" is a rather horrible way of describing the challenges that many good IT professionals strive to find in the workplace.

        The words "challenging work environment" likely exist on your own resume, as they do with most people who are good at what they do and enjoy the challenge. I didn't get into IT because I enjoy sitting around a room babysitting boxes full of blinking lights and hard drives. I sure as hell don't stay

        • by Bengie ( 1121981 )
          The only thing challenging about technological solutions is the people you have to deal with to get your job done. In 10 years of programming, I have yet to run into a situation where I couldn't immediately see what needed to get done. "Challenging work environment" sounds like working with a lot of idiots. Of course I understand what you meant. aka "Not boring".
          • by AuMatar ( 183847 )

            Then you've never worked on anything non trivial. Most likely because you aren't good enough to be trusted with it.

            • by Bengie ( 1121981 )
              "Trivial" is relative. Non-trivial but fun to me is multi-threading, I actually have to try and it typically takes me a few days to create a high performing easy to debug design. The company CIO has thanked me for such an outstanding job of taking on projects that other teams are too afraid to do. BTW, we're partly owned by Google, and Google and Microsoft have both come to us for help and are partners.

              I would love to work on bigger projects, but there's a lot of red-tape to break into those.
      • by tomhath ( 637240 )

        Back in the day, we could predict how buggy a section of code was by two things:

        1) Who wrote it. Some programmers always write buggy code, no matter how simple the problem they're trying to solve

        2) How much logging / commented out print statements were in it. More debugging always meant the programmer was struggling to get it working and was afraid to clean it up when they thought they were done.

      • It doesn't measure "if the programmer was over or under-qualified to write the particular code" either. (IDNRTFA) but sounds like it measures biometrics such as heart rate relative to the code module shown on screen. I am guessing that the researcher assumes a cause and effect relationship between code difficulty and heart rate, presumably, since they detected a correlation when testing in controlled environment. I assume that they then assumed the "real world" functions the same as their "controlled e
      • by ilctoh ( 620875 )

        If the coder struggled but the result turned out great then the method will still flag the code to be likely to be bad. The method will also completely miss buggy code caused by the programmer not realizing that the problem is tricky and going for a way too simple solution.

        I agree that these factors mean that the test cannot be reliably used to just identify potentially dangerous parts of code. But I think the results could reveal some interesting information about the programmer.

        As you said - if we have data showing that a developer struggled with a particular area of code, but that area ends up being of high quality - then we can see that the developer likely has a great attention to detail, and is being thorough with his design and testing. That's good information to

    • by Big Hairy Ian ( 1155547 ) on Monday May 23, 2016 @05:59AM (#52163439)
      It's all spaghetti code in the end
  • by Anonymous Coward

    that all my code is terrible.

  • Subjective (Score:5, Interesting)

    by eWarz ( 610883 ) on Sunday May 22, 2016 @10:40PM (#52162535)
    The problem with code quality is that it is subjective. Some people (aka architecture astronauts) love complex, multi-tiered code with multiple classes and tons of inheritance. Others prefer the simplest code required to get the job done. Still others like some type of balance between the two. Code, much like art, cannot be judged because of this.
    • The problem with code quality is that it is subjective. Some people (aka architecture astronauts) love complex, multi-tiered code with multiple classes and tons of inheritance. Others prefer the simplest code required to get the job done. Still others like some type of balance between the two. Code, much like art, cannot be judged because of this.

      They aren't detecting code complexity, they are detecting which parts were complex/difficult for the programmer and therefore more likely to contain bugs. This might even indirectly detect readability. If something is "multi-tiered code with multiple classes" and that makes it easier to understand then the biometrics should detect that. On the other hand, if the "multi-tiered code with multiple classes" makes it overly complex and harder to understand then again, the biometrics should show that.
      So, yes,

      • by AmiMoJo ( 196126 )

        Code quality depends on the situation. On an embedded system with limited resources running from a battery it makes sense to make certain compromises that you wouldn't take on a desktop system. The problem with any system like this is that the PHB will run it without understanding that it needs tuning or interpreting, and act on the good/bad output.

        • Code quality depends on the situation. On an embedded system with limited resources running from a battery it makes sense to make certain compromises that you wouldn't take on a desktop system. The problem with any system like this is that the PHB will run it without understanding that it needs tuning or interpreting, and act on the good/bad output.

          Yes, code quality depends on the situation but what you are describing is not what the biometrics are measuring. A better example might be that coding for embedded system is harder and more stressful but it could still be argued that if the programmer is stressed that he is more likely to make mistakes because that is really what they are measuring. More stress and/or more brain activity implies that it is not as "second nature" to the programmer and therefore harder and more accident prone. This is basi

    • While I agree that code quality is subjective, but everybody loves the simplest code required to get the job done. This simplest code will have the highest quality because it is the easiest to understand. If code is easy to understand it has a high quality.

      • Should I write a higher-order function to generalize over a class of mappings, or should I write an inlined loop performing the operation wherever I need it? The former will probably be longer, but in the place where it's being used, there will be a descriptive name for the general transformation pattern. Or maybe I could even make a few local definitions describing what the generic transformations are supposed to be used for in the particular piece of code I'm just writing, and then just compose the even m
    • by Ace17 ( 3804065 )
      Let's not throw the baby out with the bath-water. Although there certainly is a subjective part to code quality, the objective part is big enough to be considered.
      Put those architecture astronauts in front of somebody else's code, and they will prefer the non-astronauts versions.
    • Personally, I think the code should work, and that others can read and understand it in order to make modifications. Sounds simple enough, yet so many people screw that up since they only focus on the first part. The second part presumably is either forgotten about or purposely skipped for some sort of misguided job security.

    • Code, much like art, cannot be judged because of this.

      Code, much like everything else in life, will be judged - whether you think it is fair or not is irrelevant.

    • by PJ6 ( 1151747 )

      The problem with code quality is that it is subjective. Some people (aka architecture astronauts) love complex, multi-tiered code with multiple classes and tons of inheritance.

      Bite your tongue. You show me an architect that uses tons of inheritance and I'll show you a paste-eater.

      Unnecessary complexity is the greatest sin you can commit in engineering. Quality is NOT subjective.

  • Obviously we need programmers to work in interactive debuggers at all times, and, when the environment detects a bug, it gives the developer an electric shock. The shock would be mild at first, but would increase in severity for each subsequent bug. After twenty bugs have been detected in a single day, the program could automatically terminate the employee and outsource the project to an offshore resource.

    I'm sure this approach would increase both software quality and employee morale, just as it did at Milg

    • by __aaclcg7560 ( 824291 ) on Sunday May 22, 2016 @11:03PM (#52162605)

      Obviously we need programmers to work in interactive debuggers at all times, and, when the environment detects a bug, it gives the developer an electric shock.

      As a lead software tester in a former life (I currently do government IT work), I've always requested the use of a cattle prod when talking to the programmers about they think the user is supposed to do with the application and what I've proven user can do to crash the application. "Users don't do that!" isn't a valid excuse for not fixing a crash bug. My requests for the cattle prods were always denied by management.

      • by Rande ( 255599 )

        On the rare occasions where I, as a user, have reported a repeatable crash in a program, the response has been "It crashes when you do that? Well, don't do that."

      • by TapeCutter ( 624760 ) on Monday May 23, 2016 @02:49AM (#52163045) Journal

        "Users don't do that!"

        I've heard that phrase from sales executives and non-technical managers, but never from a developer.

        Disclaimer : 25yrs experience as a software-dev of various rankings, spent a lot of that time working with formalised test teams.

        • I've heard that phrase from sales executives and non-technical managers, but never from a developer.

          For sure. Most developers I know have their own personal battle scars from users doing weird, unexpected stuff to break things. "I don't need to validate this function input - it should always be valid coming in." "Yeah, well you should probably do it anyway." Sure enough, an exception ends up in the logs at some point.
      • A real tester would never use a cattle prod he's use thumb screws if you need to use a cattle prod you'll need an automation tester
      • by tomhath ( 637240 )

        I've proven user can do to crash the application.

        Every bug fix should be accompanied by a cost/benefit analysis. E.g. entering a number for a person's age which is greater than 4 billion causes an error. Okay, is it worth fixing? Not unless you have a team of developers sitting around with nothing else to do.

    • by rtb61 ( 674572 )

      It can not be forced. If the coder is producing happy fun brain chemicals when producing code it's because they a genetic tilt to that kind of mental activity, they get in the zone and the work is fluid. Sure they can head off in the wrong direction but they can change course and still produce the final quality outcome. So all in the brain chemicals, not that you can produce similar output by feeding those brain chemicals into another individual, those brain chemicals are a result of the happy fun thought

    • * Milgram

  • It sounds like this method doesn't identify bugs, it identifies sections of code where the programmer was under stress. Those are likely candidates for sections of code where bugs can occur, but the developer likely already knew that. It doesn't help at all in figuring out exactly what errors there are in that stretch of code, and it won't help in deciding where to test because you should already be testing all the code. If you aren't, you've got bigger problems than merely bugs in the code and you likely w

    • Not necessarily stress. Heart rate could be up because someone is doing something interesting and the dopamine goes up. But then they themselves won't understand what they did once the excitement wears off.
  • by manu0601 ( 2221348 ) on Sunday May 22, 2016 @10:55PM (#52162579)

    I have the feeling that most bugs are produced by developers that overlook usual problems: not validating inputs is the best example. This is a well known problem, but it sill happens.

    In such a case, the problem is that the developer just does not care. He/she will happily split bad code without altering any biometric signature.

    • It could also be that most bugs show up in code where the developer is most confused and thus feeling stress.
    • I have the feeling that most bugs are produced by developers that overlook usual problems: not validating inputs is the best example. This is a well known problem, but it sill happens.

      well said'); drop table students;

      • by iceaxe ( 18903 )

        I have the feeling that most bugs are produced by developers that overlook usual problems: not validating inputs is the best example. This is a well known problem, but it sill happens.

        well said'); drop table students;

        Bobby? Is that you?!

    • by Buchenskjoll ( 762354 ) on Monday May 23, 2016 @02:29AM (#52163003)

      not validating inputs is the best example

      but it sill happens.

      There, you proved it!

    • by AmiMoJo ( 196126 )

      I wonder how well it could detect the accumulation of technical debt or the lack of safety features.

      Can they tell the difference between a programmer thinking "okay, I had better make item 0 in this state enum an error condition, so I can detect errors, which means I need to write some extra error handling code and the deadline is fast approaching" and "meh, there's no way that can ever happen". The former creates more stress and anxiety. Is stress and anxiety weighted positively?

  • by MillionthMonkey ( 240664 ) on Sunday May 22, 2016 @10:57PM (#52162585)

    When I'm in a coding interview that never ends where I also happen to be naked, that tips me off right away that I'm dreaming. Seriously, I can walk through a doorway or climb through a window and suddenly all my clothes vanish at once and everyone is looking at me. So when this happens, I instantly know, aha, this is a dream. So I start telling people that I'm lucid dreaming, that they don't actually exist, and that I'm stuck in this fake dreamworld that I can't escape but where nothing I do or say really matters anyway.

    Typically these nonexistent people will say, "Wow, it must suck to know you're trapped in a dream naked... but anyway how do you write a recursive function that can detect a cycle in a linked list?" Questions like that usually make me forget that I'm dreaming.

    • by SeaFox ( 739806 )

      Cool story, bro.

    • anyway how do you write a recursive function that can detect a cycle in a linked list?"

      I'll be honest, of the many bugs I've had in my code, managing to get a cycle in a linked list is one I've never had. I'm 100% perfect at not getting cycles in my linked lists. Wow, go me!

  • As a male, if I'm naked, I'm empowered, because I'm OK with being seen, and the viewers may not be (and, no, not because my body is gross; in fact, it is OK). Were I female, except for a limited subset, then the power is in the viewers hands, rather than mine.

    • by mentil ( 1748130 )

      You're empowered if people are pointing and making disapproving looks? Maybe while laughing at your 'shrinkage'? Doing something you're not ashamed of that others disapprove of doesn't automatically empower you; society has a counterbalancing force, generally the police enforcing 'disturbing the peace' type laws.
      Now, if you mean being nude at work (casual fridays at Pornhub?), rather than in public, then, ignoring sexual harrassment issues, that'd only give you -- at most -- the power to get people to leave

      • by dltaylor ( 7510 )

        The difference is that nude females are assumed to be "asking for it", while nude males are assumed to be just weird (outside of "proper" contexts).

        • by Livius ( 318358 )

          If, however, the nude female actually is asking for it, she's wielding vastly more power than any man could ever dream of.

        • by Anonymous Coward

          ... while nude males are assumed to be just weird ...

          I argue that nude males are threatening rape while a nude female is 'harmless'. No man is going to complain that a nude female demanded sex. Except for "It couldn't happen to a nicer guy" (1974), men don't feel powerless against horny women.

  • The heart rate increases were actually due to taking a moment to think about how to approach a problem... while slamming a Mt. Dew. Or taking a gulp of coffee. Whichever caffeine delivery vehicle is preferred.

  • Code quality measured in FPKLOC. Guess what that metric is.
  • by GoodNewsJimDotCom ( 2244874 ) on Sunday May 22, 2016 @11:28PM (#52162659)
    If they can determine when a programmer is drunk, odds are the quality of their code is bad... for that individual programmer. Programming skill is so varied that I'd take a drunk quality programmer over sober riff raff.
  • That research is a whole lot of bullshit. Code quality by heart rate and bio-metrics! Ah!
    Come one! Code quality assessment needs code quality check, that is code review, unit tests and the (usual) likes.
    Do you want to save money? Make it opensource, put money in the opensource and you'll be paid back.
    Share your code!
  • by Cesare Ferrari ( 667973 ) on Monday May 23, 2016 @01:14AM (#52162873) Homepage

    You know, if you asked me which bits of my code where the hardest to write, and likely to contain bugs, I can tell you. In fact, I usually comment on code reviews in this way to help direct a reviewer to the bits I think need attention. Being self-critical is a very useful skill, accepting your limitations, asking others to help.

  • What if you write really shitty code but you're really confident and sure of yourself while you do it? Certainly this type of system would be largely easily fooled by the same mechanisms many inexperienced coders use to fool themselves and their employers?

  • Will the system recognize when I find a piece of code that's an illegible thousand line file filled with SQL queries and no comments as to their purpose? Can it predict when I've been given a task to modify this code and won't do a good job because it's like shitting on a pile of shit? Or is the idea that it will catch the perpetrator of this dung pile and hold them responsible? What if the person who wrote this turd station was completely comfortable shitting onto a keyboard and into a codebase? Their hear

  • "...happen to be naked" as if it's a bad thing.
  • This is more like Phrenology than anything else. It's absurd and pointless.

  • Just wrote a bitch of a piece of code. I aborted when I fully appreciated that the data model I was adopting simply stank. The crap code code is gone and a cleaner approach now results in actually readable code. The former surely caused my heart rate to rise. The latter to drop due to absolute boredom.

    Would the Zurcher team take into consideration that some people actually see sense and backtrack? Or should good coders be visited by ties to be told what they already know?

  • We need unions to stop Biometrics / DNA BS be for you need to have the rights to get the job and when you fail that DNA test will MC'd min wage job help you pay off that big student loan?

  • So, a freelance, work-at-home job then. Or maybe it's just *that* dream again. Possibly both?

  • "On the other hand, Motherboard likened the stress level for programmers to 'a coding interview that never ends where you also happen to be naked. '"

    Really? I'm surprised by this. I almost never feel like this. To be sure, occasionally I get a little stressed out when something isn't working right, but for the most part I am quite relaxed and content while coding. And it's not like everything I do is easy either. I'm often the only guy in the shop who is willing to try something new.

    It does seem like t

  • It's really hard to find who is a good contributor and who is a good pretender in a team. Surely in future AI/big data is going to assist the management if figuring out whom to keep and whom to fire when they want to cut-cost. Measuring your state at work (including how long you take breaks, are you distracted while coding, how your body systems are working (biometrics)) will surely aid in figuring out who gets to be kept. I think today it's mostly politics which play a greater role in the firing time but
  • I guess much bad code is just really complicated and the alternatives are different versions, one being as bad as the other one.

The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Working...