Wiring Programmers To Prevent Buggy Code 116
mikejuk (1801200) writes "Microsoft Researcher Andrew Begel, together with academic and industry colleagues have been trying to detect when developers are struggling as they work, in order to prevent bugs before they are introduced into code. A paper presented at the 36th International Conference on Software Engineering, reports on a study conducted with 15 professional programmers to see how well an eye-tracker, an electrodermal activity (EDA) sensor, and an electroencephalography (EEG) sensor could be used to predict whether developers would find a task difficult. Difficult tasks are potential bug generators and finding a task difficult is the programming equivalent of going to sleep at the wheel. Going beyond this initial investigation researchers now need to decide how to support developers who are finding their work difficult. What isn't known yet is how developers will react if their actions are approaching bug-potential levels and an intervention is deemed necessary. Presumably the nature of the intervention also has to be worked out. So next time you sit down at your coding station consider that in the future they may be wanting to wire you up just to make sure you aren't a source of bugs. And what could possibly be the intervention?"
Take it a step further... (Score:3, Insightful)
...make sure you go back to the business guy who create the requirements being coded at the time, hook him up to an EEG, and see if he wrote a buggy spec :) ...for bonus points, put the EEG on the manager who just said they're going to measure productivity in LOC.
If we could detect stupid with an EEG, programmers would probably be the least useful people to put it on.
Hi, it looks like you are writing difficult code! (Score:5, Insightful)
The last thing I need when I am focused of a difficult chunk of code is Clippy popping up and breaking my focus. Some tasks are just much harder than others. I think any decent coder knows when they are struggling and increases their focus or grabs someone on their team to help. Bad coders may not, but bad coders are always bad coders, and no tools will help someone who just can't get it or just doesn't care.
Breaking things is how we learn (Score:4, Insightful)
Doing hard or unfamiliar tasks is one way we improve and grow. Mistakes improve our understanding of a domain.
Flagging code for extra review based on "struggle detection" *might* be useful. Sadly, we all know that we'd end up with clueless management punishing or even firing good people because they were stretching to meet a goal.
Get rid of the distractions (Score:5, Insightful)
Bugs come when people lose track of the big picture. When they lose concentration and focus - just like when jugglers drop the ball.
If you want to reduce the incidence of avoidable bugs, get rid of the distractions. Ones such as other people interrupting, phones ringing, asynchronous non job-related alerts going off (fire alarms excepted) and the administrivia associated with the programming environment. Maybe even unplug them from their "entertainment", too.
There will always be non-avoidable bugs: ones where the programmer is simply making a mistake, isn't up to the task in hand or has been given a bad brief or wrong information.
Not all bugs are in difficult code (Score:4, Insightful)
Completely ignores bad specs... (Score:5, Insightful)
While completely ignoring that the specs handed down from the higher-ups are gibberish, contradictory, and physically impossible garbage. But, you know, that is not a possible source of bugs now is it?
Someone should first wire up management to zap them every time they get an idea for a "brilliant" addition.
Re: No silver bullet (Score:5, Insightful)
Difficulty act as a motivator, and helps developpers to focus. Most bugs I've seen (or caused) are on easy, boring tasks.
Yes (Score:5, Insightful)
Bugs mostly come from when you're not paying attention, or you forgot something.
If you've doing difficult coding then writing code is the last thing you doing be doing. By the time you get to writing code it shouldn't be difficult anymore.
Propaganda requires reinforcement. (Score:5, Insightful)
That they continue to try and blame programmers for problems that management creates should bother people. Yes, this is a rewording of the same article. The only way to sell this alchemy (I would not even call it pseudo science) is by continually bleating out the theme "programmers are baaaad and we can detect them being baaaaad".
Lets just say (though its impossible for them to do) that they can isolate every possible variable that would cause fluctuations in EEGs, heart rates, and everything else they want to track biometrically. How on earth do they plan to track and correlate that data without either knowing or directing everything you eat, drink, and touch (including shampoo, soap, and hand lotion).
Even better, how do they plan to either direct or track all of your personal interactions which can impact those same things. If they can't, then the numbers are skewed and we don't have any science, you only have biases.
Oh, I can see it now. "Monty. We know your dad died yesterday but you are performing sub par and your heart rate is elevated higher than we expect, so we are going to have to let you go. We can't have a repeat of your three days of sub par performance when your wife divorced you five years ago."
Now lets look at some of the great Microsoft Management decisions, and decide who's to blame: Programmer or Management. Lync can not copy/paste data. Do you really think a programmer didn't notice the lack of basic function and point it out? Windows 8, and in fact Microsoft's whole "One UI" strategy is management driven. Zune, was actually a decent device but management killed the program. Programmers said Win8 was not ready, Management released it (as they did with Vista, ME, countless back office products, etc..). Programmers have had fixes for security ready only to have them pulled by management for various reasons. "Can't fix that IIS back door because someone's code may break" is frigging hilarious, but how many times have we read just that from Microsoft management?
That list could get really really long, so here is the point. Why are they not hooking management up to these things and putting them under pressure instead of the programmers? Probably for the same reason I start with, which is that this is alchemy and not science.
How about this. (Score:4, Insightful)
Re:Not as novel as it sounds (Score:2, Insightful)
The procedure is just a variant of letting the programmer write a piece of code and then hook him/her up to a polygraph and interrogate her/him if the code has any bugs, and if it does, in which source file and line number....
"Does this code have any bugs?"
"Yes, like all non-trivial programs, this program has bugs too."
"Where is the bug?"
"If I knew, I would have fixed the bug already. But that's not the point. There's always one more bug that haven't been found yet."