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. "
that all my code is terrible.
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.
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.
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.
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.
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.
God spoke to me
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...
It's all spaghetti code in the end
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Btw, you are threading a very thin and dangerous line, when you are suggesting, that some more experienced developers should be loaded with tasks... in the first instance - the question is what those "less experienced" developers are doing in the company, if they are earning the same salary and making bugs!
Why would a "less experienced" junior developer be earning the same as a "more experienced" senior developer?
Basically - what are you suggesting is that it is ok to make more experienced developers more stressful... because clearly, if there are people who can't code, why would you even bother to keep them on expense on somebody else nerves?
That's not what I am suggesting at all. Rather I'm suggesting that you could detect when you gave someone a task that they weren't ready to tackle yet and would be better off giving it to someone with a little more experience. The person with the more experience should hopefully find the task easier and therefore not as stressful.
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.
If code is repetitive enough, there should be an app (developed) to do that.
Nobody follows patterns as well as a program. And, if the pattern needs changing, change the program that writes the code - it will rewrite the code for you in the new pattern in milliseconds.
if you can't code without the help of the internet, you are not a coder.
Whatever. I get paid for functionality, not originality.
"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.