Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Microsoft Programming Software Science

Researchers Test Developer Biometrics To Predict Buggy Code 89

rjmarvin writes: Microsoft Research is testing a new method for predicting errors and bugs while developers write code: biometrics. By measuring a developer's eye movements, physical and mental characteristics as they code, the researchers tracked alertness and stress levels to predict the difficulty of a given task with respect to the coder's abilities. In a paper entitled "Using Psycho-Physiological Measures to Assess Task Difficulty in Software Development," the researchers summarized how they strapped an eye tracker, an electrodermal sensor and an EEG sensor to 15 developers as they programmed for various tasks. Biometrics predicted task difficulty for a new developer 64.99% of the time. For a subsequent tasks with the same developer, the researchers found biometrics to be 84.38% accurate. They suggest using the information to mark places in code that developers find particularly difficult, and then reviewing or refactoring those sections later.
This discussion has been archived. No new comments can be posted.

Researchers Test Developer Biometrics To Predict Buggy Code

Comments Filter:
  • by dave562 ( 969951 ) on Tuesday July 22, 2014 @03:05PM (#47509711) Journal

    The world hates putting up with buggy code.

  • by nimbius ( 983462 ) on Tuesday July 22, 2014 @03:17PM (#47509781) Homepage
    When your developers cringe at a project, when they encounter a subroutine or callback that literally makes them groan, you've found exactly what needs to be refactored. if you find a python wrapper around a godforsaken class, or find explitives cursing a dead gods name in a forgotten universe, thats the code that needs your attention. Project managers, section leaders, whoever has direct line-of-sight communication with the dev pit needs to pay more attention.

    the problem is 'refactoring' is a lie. as a DevOps (christ i hate that fucking word) engineer, I've been faced with rotting festering codebases for years in my career on a daily basis. the issue is business priorities interfering with good coding practices. I and 2 junior devs might want to go rip up a few thousand lines of horror-code to make everyone more productive, but we get denied. why?:

    1. downtime is unacceptable for this application. this code controls so much, does so many things, and is so obscure (say it with me, payments processing subsystem) that to do ANYTHING to it is literally worse than pistol whipping the CEO's daughter.
    2. New New NEW! we need to get in those swim lanes and stand up in those scrums nice and straight so we can deliver optimum ROI to our dear customers! who cares if the system crashes 5 times a month because this module is satans petrified asscrack, google just launched their new $app so our new $cloud_app_pro needs to go live NOW!.
    3. we had the resources, but uber elite coders in our ranks were ganked to other projects months ago. they havent seen the code in 3 months, and we're sure they'll be along to help us again once they put in their 2 weeks and show up in flip flops for the knowledge transfer.
    4. you were ganked from the refactor project and are now plugging away at an irritating new web 9.0 cash money matic piece of code that marketing wont stop skullfucking and your boss cant deliver fast enough. Catch this rabbit though and you'll be able to sit down and think through...wait....what was the refactoring project about again? oh christ is that CVS?

    what this technology will get used for
    efficiency sampling in your dev groups. eye tracking and biometrics will now subtly be included in SCRUM/ITIL/six sigma/devops/management wankfest.
  • by netsavior ( 627338 ) on Tuesday July 22, 2014 @03:21PM (#47509821)
    because the average judge/jury/CEO/consumer/manager has no idea how to write code.

    They can understand how a toilet is cleaned, how a sale is made, how a 1099 is filled out, how a fire drill works, how a sandwich is put together, how oil is changed, etc... but Coding might as well be a dark art.

    Developers are part of a very narrow segment which has no reliable Key Performance Indicators. [wikipedia.org]
    Part of that is developers are smart enough to game any system, because they can think in algorithms.

    Want to track productivity on Lines of code? Fine, Developers can do NO WORK, and produce TONS of code
    Want to track productivity on Number of defects introduced? Fine, doing NO WORK is the baseline for perfect.
    Want to track productivity on Number of defects fixed? Fine, through the magic of hand wavery, defects can be found and fixed with no actual work happening

    Compare that to well-defined Key Performance Indicators for sales... Bring in X dollars of sales, your performance is X.

    CEOs HATE things they cannot measure... which means CEOs are a natural enemy of Developers.

Why won't sharks eat lawyers? Professional courtesy.