I'm incredibly intrigued as to how they are sure they are not measuring the reverse direction. That is, developers in a poor process and badly managed product are likely to be unhappy. Not that unhappy developers are likely to poorly follow process and create poor software.
I'm not asking to throw out the results. I want help understanding how they are able to make this claim.
I'm going to go out on a limb and say it's inversely proportional to skill.
That is, skilled developers will want a better product/process and they will want to work with other skilled devs. Putting them in less-than-ideal situations causes frustration.
OTOH, a poorly skilled dev will want to push the environment in the other direction, for no other reason than to obfuscate the lack of skill. Putting them in an ideal situation for the skilled dev causes fear. Their aim is job security.
I do not think it is that simple. Skilled developer can still be pretty fine with bad process, as long as worst consequences of the process don't fall on him personally. So when juniors have more mistakes as a result of not knowing requirements or code changes (process does not help to broadcast information), the skilled developer is fine - he is doing most code reviews so he personally knows enough and has control. Skilled developer in that situation will resist changes, because he is fine - it is just that juniors are less capable which strokes his ego.
Or when junior are increasingly demotivated due to excessive micromanagement (bad process), skilled developer is perfectly fine - he is the one doing micromanagement. The fact that juniors could learn faster and achieve more will escape such developer.
Moreover, more skilled developers are oftentimes better able to offset the bad process. The less skilled developer pays more price for bad process - it turns him from able to do work into unable to perform the work.
Technical skill and ability to organize or see through process are not the same thing. You wont be able to organize if you do not have enough of technical skill, but technical skill in itself wont make you able to create good process.
I mean much more than technical skill... communication, delegation, mentorship, humility, culpability, etc. The hallmarks of being a good teammate in addition to someone who can sling code. Character is important.
If someone like this is in a situation where they need to micromanage or mitigate that is going to be a source of frustration. If someone has dysfunctional or antisocial tendencies and that's the reason why they're technically excellent, yes, they will gravitate toward chaos, just like they would probably gravitate toward a co-dependent relationship in their personal life.
Also to be clear, when I say skilled I'm talking about relative to the expectation of the position. A skilled jr. dev will be one who possesses the potential for greatness and who does good work at that level. As a sr. dev may enjoy mentoring others, a good jr. dev will seek out mentorship. And an ideal environment will be conducive to and support these types of relationships.
Bad devs are devs who just haven't spent as much time thinking about software, they probably don't consider themselves bad developers, and they sure as hell aren't sabotaging projects.
"Bad devs are devs who just haven't spent as much time thinking about software"
I would say they lack the character to overcome their flaws... lack of intellectual curiosity and humility. I've worked with quite a few people with 10+ years of experience at large enterprise companies who were flat out dangerous to a project and had to be managed as to what they worked on. People with senior titles who were functioning at a junior level, who simply got the title due to the number of years of "experience".
At one place I worked I literally saw a team form from the outcasts of other teams. All they did was copy translated strings into string tables and crystal reports and resize elements on screens in cases of overflow. It was literally data entry. All 5 were highly paid sr. developers. When layoffs started happening at that company they were one of the first groups to get axed... one of them I keep in touch with took two years to get a job, and another recently reached out to me asking for any leads. He hasn't worked in nearly 4 years. I gave him some tips for career development and self improvement, he didn't care, he just needed a job.
"they probably don't consider themselves bad developers,"
That's a problem. Knowing your limits/flaws is pretty crucial, a bad developer tends to have an outsized view of their abilities. Conversely, good developers tend to battle imposter syndrome during periods of growth.
"they sure as hell aren't sabotaging projects"
Maybe not intentionally (or at least they view it that way), but incompetence has a funny way of dragging down a team. Not putting in the effort to properly understand the domain of the problem or the business model, architecting confusing/overwrought solutions which lack conceptual integrity, not communicating clearly on progress, trying to confuse instead of admitting they don't know, etc.
There are plenty of things that affect happiness and therefore productivity if you follow their assertion.
The stress of trying to pay rent in tech cities being one I can think of. Would be interesting to see if developers in more easy going places are more or perhaps less productive.
It doesn't look like that's the point. It looks like the point is to have a good starting point for further studies that will use the same codification for surveys and questionnaires so that various studies can be compared.
Unfortunately without putting randomly assigned teams into controlled settings to test this, how else can we figure that out? I want to know too, but this seems expensive to test to any high level of certainty for the causation.
Welcome to the fuzzy world of social sciences my friend! More seriously, these guys need some help from other disciplines (psychology, sociology or business administration). There are so many ways this thing could go wrong... Reinventing the wheel can be a cool side project, but won't get you published anywhere.
Randomly assigned teams sounds like any straight out of college hiring pipeline, although controlled settings is harder. Google has done research on this, although I don't think they've done much with it.
I agree, the title is certainly overconfident if not negligent. Preventing people from writing inaccurate communications would be the topic of many studies and papers by itself though!
Yes it matters. You have to know the direction of causality.
Consider it in different words. "Tired people are bad for themselves, for process, and for projects." To many, this will read as "hire folks that aren't tired." Worse, it will be "your folks are tired, so they will make things bad for themselves, their processes, and their projects."
At best, you will get people who will see it and victim blame in a way that won't help. "You are jeopardizing our ability to succeed with your tiredness. In addition to your current tasks, I'm assigning you the job of getting less tired." So... odds of increasing wakefulness, slim.
Now, it could turn out that it is something you can fix in this way. I don't know and that is my point.
It does matter. If unhappy developers cause bad software then the solution is to make the developer happy and the software will fix itself. If it's the other way then the process is the one that needs fixing.
For current issues yes, it doesn't matter you just fix it and get the results. If you want to prevent it in the future it helps to know which one causes the other. Then you can focus preventative efforts on the factor that causes the issue.
Unhelpful sedition twoards, or deviation from, corperate montra is banned employee 453297. Please pack your bags, family, self-supplied toiletries and proceed to the incinerator.
It's an academic study, and I thought this was computer science. Of course you're going to see conclusions that sound simple and obvious, it's just now you'll have actual stats across multiple studies and teams and companies and developers to prove this rather than anecdotal evidence.
The bottom line is a balance of functional requirements (e.g: user facing features) and non-functional requirements (e.g: maintainability, performance). Software that doesn't implement non-functional requirements has a name: a functional prototype.
Bad engineering feels like taking a loan of technical debt to pay your manager, so customers can be scammed receiving a half finished product for the price of a finished one.
In the other hand, when you do good engineering you can proudly stand behind your work, be motivated and engaged.
You can sell a functional prototype for a while, until customers start massively reporting bugs, someone finds a severe vulnerability, or you end up with a 1000 developer payroll to compensate for low maintainability and people getting checked out.
Sometimes it's better to invest a bit in other aspects as well. Of course, you don't protect a $100 bike with a $1000 lock. There are tradeoffs.
Our product sucks because we have no vision, our process sucks because upper management is entangled in turfs wars, it's probably because our developers are unhappy.
Page length is a common indicator, though it varies by conference. This paper is 3 pages, which is in most subfields of CS a typical poster-paper length (2-4 pages), with full technical/research papers being 6+ pages. But in this case it also says so on the arXiv page.
The comments section says it's to appear as a poster. I don't know how it is for the organization hosting that event, but when I was a physics student, every member of the physical society was allowed at least one publication per year. So anybody who didn't get a paper or a talk, could do a poster, and their abstract was printed in the proceedings. I don't know if it was an official rule, but it's what happened in practice. I think it was not a bad approach, as it meant that nobody could say they were denied publication of their idea.
It was also fun to visit the crackpot posters. Some of the authors went to a huge effort, including having their own books printed, and so forth. Plus, there was usually beer at the afternoon posters.
In CS typically the poster track is peer-reviewed like the main track, just with different standards that are oriented towards allowing people to present preliminary work, minor experiments, etc. However it is still supposed to be interesting and competent work, and you can definitely get rejected even with a non-crackpot poster submission if it's one of the more competitive conferences. You usually have to submit a paper for peer review, but a short one, <4 pages. At some, it may also be a consolation prize for rejected full-track papers, where work that doesn't make the cut but is still interesting is offered a space at the conference if the authors are willing to submit a cut-down version as a poster paper.
It looks like it's just a starting point to be used for future studies so they all have similar classifications and coding for surveys/questionnaires.
I'm also not sure how low of a bar it is when they did a study, coded the results, creating a coding system for surveys that can be used by others, and did more research to make sure they were asking the right questions.
I'm willing to bet that this is the first paper in a series of them and they'll use it to grab more grant $$ to do more in-depth research.
I'm not asking to throw out the results. I want help understanding how they are able to make this claim.