From the abstract, it sounds like the actual paper makes less bombastic claims than the news sites talking about the paper:
"In a field study with ten professional developers over a
two-week period we investigated the use of biometrics to
determine code quality concerns. Our results show that bio-
metrics are indeed able to predict quality concerns of parts
of the code while a developer is working on, improving upon
a naive classifier by more than 26% and outperforming clas-
sifiers based on more traditional metrics. In a second study
with five professional developers from a different country
and company, we found evidence that some of our findings
from our initial study can be replicated. Overall, the results
from the presented studies suggest that biometrics have the
potential to predict code quality concerns online and thus
lower development and evolution costs."
Unfortunately, Boing Boing has gotten increasingly clickbaity in the past few years, and Cory Doctorow in particular has a strong tendency to write about the story he would have enjoyed reading instead of the one that was actually published, up to and including lying outright if it makes a more exciting article. (E.G., the 2014 article "Small Town Sheriff Buys Tank," which opens "Rural counties across Indiana have been purchasing Afghanistan-surplus tanks with gunner turrets..." It turns out he's talking about armored trucks with no weapons.)
I'm not sure if he's doing it on purpose or if he's having genuine issues distinguishing boring facts from exciting fiction, but either way Boing Boing shouldn't be trusted at all. Shame, as they used to be quite good.
Gunner turrets do not necessarily include permanently mounted weapons. See: B-17 waist-gun turrets. All weapons in the plane were removable. Nobody wants to leave automatic weapons lying around where they would be easy to steal.
Your link includes an armored vehicle in which an automatic belt-fed weapon could be mounted (and which are commonly possessed by SWAT teams). It's a military-grade APC, there is no honestly viable quarrel with his title.
Yes, it's a very common practice for news/buzz sites, broadcasts or anything else relying on content written by a person paid per view (let's say everywhere, it's easier).
I just read this article & even skimmed the study, but I can't figure out what the relation of stress to code quality is. Poor quality is high stress? Or high stress means that you are meticulous and are likely to produce higher quality code?
It would be interesting to see this linked to interviews too where the entire situation, mannerisms of the interviewer, and presentation of a given exercise are all specifically tailored to make sure it is perceived as difficult.
I am obviously making an educated guess based on experience here, however I believe that answer to why the stress is high is what causes reduced code quality rather than the stress itself.
For example, if you're under the pump and have unrealistic deadlines, you are more likely going to write less quality code. Not because you're trying to cut corners, but because when you have the time, you go over your code an improve it about five times before submitting it and have a freer mind to do that.
IMO, experience indicates that the best code quality comes well away from deadlines. Code written just before a tight deadline or during the recovery period afterward could always use extra scrutiny.
Is it really a surprise that the distractions, disruptions, and fatigue of stress affect a task that requires significant focus, concentration, and creativity? Or that not having much time to review and revise your work will result in lower quality than if you did have the chance to improve it?
Kind of strikes me as a "Breaking news - water is wet!" announcement.
I agree with that. Seems like fairly common sense. Process for a developer is to be immersed into their code and to constantly improve it so when there's no time to do that and high pressure, then it's obviously going to be lower end result quality.
"Our analysis also shows that code elements that are perceived more difficult by developers also end up having more quality concerns found in peer code reviews."
How is this surprising in any way whatsoever?
Why does it matter if it's surprising? Science isn't meant to reveal surprising things. The purpose is substantiating or refuting hypotheses. The only relevance your expectation has to a scientific conclusion is in determining sources of bias.
I'd suggest as a feature to measure the amount of time spent in editor, terminal and browser and especially on Google search, StackOverflow and Github. Also, the number of compilation errors could be useful. Another feature is to measure time spent on each portion of the source file, especially portions where the developer returns many times to make changes.
The developer text editor of the future should be able to collect features from a smart watch, camera, mouse, text cursor position, the terminal and the browser.
I'd suggest also taking into account the amount of measuring itself - there likely is a correlation between stress levels and the amount of "measuring" a programmer has to endure.
99% of the time when I'm stressed out about code I'm working on its because the product spec is overly complicated, not because the code is bad quality. Interesting study, but I don't think it matches up with real world scenarios that well.
If by "overly complicated" you really mean, "ambitious but nebulous and we need it now" then I 100% agree. Nothing is more stressful than basically being put into the position where you've been given nothing more than a couple slides worth of b.s. "architecture" and "design" and they want a working prototype in a month. Feels like you're being put in an impossible situation.
This is a jr programmer mistake, sr programmers know that a couple slides is usually enough to contain the essence of the problem, and yet not enough to paint them into a corner, make something that solves the crux of the problem, and rename a couple of your classes to items on the boxes drawn on the classes, and a couple of the methods have the same names as drawn on the lines between the boxes.
If anyone questions it, show Sr Mgmt that the class and method names match, say it works, and that everyone else is just a bunch of whiners. (The most important thing is that it works enough for a sales guy to convince the customer that it does everything they wanted)
Everyone wants a Lexus but if they're stranded on the side of the road a Lada will do quite nicely. Arriving with a Lada always make you the hero. You can go for beers with mgmt after and negotiate a raise while laughing about how you're surprised the wheels didn't fall off.
Wouldn't this be somewhat subject to polygraph syndrome? I.e. if I am being monitored my stress levels will be artificially higher as I am nervous about the monitoring.
The article is brief on details and I didn't follow any links for further study. They seem confident in their findings though so I'm sure they know better than I.
But that's the first thing that popped into my head just reading the headline...
To me, stress should correlate positively with code quality. I've met too many developers in my life that work away while listening to music from their headphones, doing a low-stress job of copying and pasting code around without the least concern for structure or maintainability. I curse and sigh all day long, but at least I try to write code that looks and behaves as I think it should, not just whatever works.
What? Copy and pasting code is not correlated with wearing headphones. The music is there to keep me focused (and to help block out open plan office noise).
I curse, too - although more quietly now everyone can hear.
Most probably it's just how my brain is wired - contrary to a lot of people, I just can't listen to music and concentrate on something different at the same time. So the idea of someone coding while listening to music makes me instinctively think they're not dedicating 100% of their brain to what they're doing. But I understand that this doesn't apply to everybody.
I have this problem too. However, being in an open-plan office, I have to choose the lesser of two evils: monotonous music vs human voices. I find the latter very distracting. I can even go to sleep with music playing but never with people talking around me. Of course given the circumstances, you could probably guess that I pick instrumental music and mainly music without strong 'movements' (I don't know the right term).
Eventually, I felt that listening to music on headphones everyday for many hours is going to affect my hearing on the long term and I decided to sacrifice productivity to keep my (better than average) hearing in good condition.
I may be rambling a bit but the point I am trying to make is that people are different and also in differing circumstances. So, is possible that you will choose likewise if you were in their place (and were of similar constitution).
I use music in order to support my development task: The playlist sets the mood like a good movie score, so the choice of music can depend on how focused and fast-paced my task is.
So many ways to predict how this study is off in the weeds before it even got started.
Doing it for something measurable like interruptions versus a fuzzy thing like "stress" would be so much easier. And then you could take action to improve things, and measure improvement.
RescueTime and others hit this broadly. Anything do it more narrowly?
While stress levels might be some degree of indicator, there are lot of other things that should make this kind of thing practically useless. Skill level/experience is going to make a really big difference.
"In a field study with ten professional developers over a two-week period we investigated the use of biometrics to determine code quality concerns. Our results show that bio- metrics are indeed able to predict quality concerns of parts of the code while a developer is working on, improving upon a naive classifier by more than 26% and outperforming clas- sifiers based on more traditional metrics. In a second study with five professional developers from a different country and company, we found evidence that some of our findings from our initial study can be replicated. Overall, the results from the presented studies suggest that biometrics have the potential to predict code quality concerns online and thus lower development and evolution costs."