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. "
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.
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.
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.
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.
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.
"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.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...