Slashdot Mirror
Code Quality Predicted Using Biometrics (vice.com)
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. "
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. "
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.
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.
"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.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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.