
Unhappy Developers: Bad for Themselves, for Process and Bad for Software Product - ingve
https://arxiv.org/abs/1701.02952
======
taeric
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.

~~~
PaulHoule
Does it matter? Fix the broken process and you get happier developers and
better productivity.

~~~
taeric
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.

------
kelvin0
"... cost-effective way to foster happiness and productivity among workers
could be to limit unhappiness of developers .."

Come on.

~~~
gravypod
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.

------
partycoder
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.

~~~
omouse
What's interesting is that the economics favour low cost at the expensive of
quality.

~~~
partycoder
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.

------
ungzd
First idea that will come up by many managers after reading this: "we should
fire those who are unhappy and hire happier developers".

~~~
JamesBarney
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.

------
darioush
Wow. What a low bar for an ICSE paper. Former software engineering PhD
student.

~~~
timtadh
It is in the poster track. That is a different (much, much lower) bar than
research track papers.

~~~
patmcguire
How can you tell which track it's in? Is it in the categories? Or is the
research track those who did it through an academic institution first?

~~~
analog31
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.

~~~
_delirium
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.

~~~
patmcguire
Ah, I see. It's not arXiv specific.

------
ommunist
What an astounishing discovery! If a horse is unhappy it does not pull the
plough well, no matter how hard you may beat it.

