
Quick start guide to research on human factors of software engineering - azhenley
http://web.eecs.utk.edu/~azh/blog/guidehciseresearch.html
======
austincheney
In my experience for most developers the behaviors boil down to just a few
questions?

1\. Are the developers willing to write original code or must they be limited
to configurations or tooling?

2\. Are the developers willing to accept any API (RTFM) or must the developers
be limited to prior known APIs?

3\. Are the developers willing to accept failure for missing unspecified, but
commonly known, requirements such as accessibility, usability, security, or
domain specific knowledge?

4\. Are the developers willing to alter their personal routines to accommodate
a shift in requirements and delivery dates or do the developers shift
requirements to accommodate their routines, such as work-life balance?

5\. Will the developers write technical documentation to describe process and
approach or will the developers shift requirements in anticipation of forth-
coming technical documentation?

6\. Will the developers refactor code to achieve simplicity (imperative),
descriptive concepts (declarative), code style, or not at all? The motivations
generally do not overlap.

7\. Will the developers accept code that better achieves business concerns or
end-user preferences (object measures) in violation to preferred structures or
styles (subjective measures)?

8\. Are the developers willing to read the existing code (RTFC) before
recommending new tools or solutions?

------
mikekchar
I really want this kind of research to flourish, but the first click I made on
an interesting looking paper led me to: "To measure tool usage, we randomly
sampled code changes from four Eclipse and eight Mylyn developers and
ascertained, for each refactoring, if it was performed manually or with tool
support. We found that refactoring tools are seldom used: 11 percent by
Eclipse developers and 9 percent by Mylyn developers."

To be fair, I haven't read the paper and the rest of the abstract looks
reasonable: "To understand refactoring practice at large, we drew from a
variety of data sets spanning more than 39,000 developers, 240,000 tool-
assisted refactorings, 2,500 developer hours, and 12,000 version control
commits."

But what the heck is the first bit for? Of 12 people I know, the vast majority
don't use refactoring tools. That's not the basis on which to launch a study.
I've skimmed the abstracts of the other papers as well and I'm not all that
impressed. Everything seems to be doing comparisons against Eclipse. While
Eclipse has a variety of different usability features, I'm actually not
convinced any of them help at all (which is why I don't use it ;-) ). So at
the very least, I'd like to see a baseline against a traditional text editor
like Emacs or Vim. The "improvements" in usability that they are measuring may
simply be the avoidance of problems in Eclipse. I'm not trying to start an
editor war here, I'm just saying you can't assume that any single editor is a
good baseline. I'd argue strenuously that feature rich editors like Eclipse,
IntelliJ, VS Code, etc, etc are particularly bad candidates because nobody has
really measured the effectiveness of their features.

Without being too negative, I hope there are better papers on these kinds of
topics because I think it's incredibly important.

