Zwischen 0 und 4 Uhr passieren Programmierern die meisten Fehler, zwischen 7 und 12 Uhr die wenigsten. Das zeigt eine statistische Analyse der Kerne von Linux und PostgreSQL.
Die Arbeit Do Time of Day and Developer Experience Affect Commit Bugginess? von Eyolfson-Tan-Lam ist dieses Wochenende auf der 8th Working Conference on Mining Software Repositories vorgestellt worden.
Modern software is often developed over many years with hundreds of thousands of commits. Commit metadata is a rich source of social characteristics, including the commit’s time of day and the experience and commit frequency of its author. The “bugginess” of a commit is also a critical property of that commit. In this paper, we investigate the correlation between a commit’s social characteristics and its “bugginess”;
Das interessanteste Ergebnis ist der Zusammenhang zwischen Fehleranzahl und Tageszeit:
Hingegen zeigen die Daten keinen Zusammenhang zwischen Fehleranzahl und Erfahrung (erfahrenen Programmierern passieren genausoviele Fehler, wobei “Erfahrung” sich im Kontext dieser Untersuchung allerdings nur auf die Erfahrung mit dem jeweiligen Projekt bezieht, also wielange der Programmierer schon bei Linux bzw. PostgreSQL beteiligt ist) oder zwischen Fehleranzahl und Wochentag (entgegen anderslautenden Vermutungen passieren an Freitagen nicht mehr Fehler):
Zur Methodik:
We define a bug-introducing commit to be any commit for which there exists a later bug-fixing commit that purports to fix the bug.
[…]
Following [19], our methodology has three steps: 1) enumerating bug-fixing commits; 2) identifying the lines changed in each bug-fixing commit; and 3) finding the commits which were responsible for the previous (buggy) version of each of the changed lines.
Heißt: erfaßt werden (natürlich) nur Fehler, die später korrigiert wurden.
Executing the above algorithm gives us data about the bug-fixing and bug-introducing commits in each repository, as well as about the authors of these commits. We record the following data for each commit: author (as a name/email pair); adjusted local time (as described below); number of lines changed; and number of times the commit introduced a bug later corrected (which is derived data; we record it to simplify later database queries). We also record a relation connecting bug-introducing commits and bug-fixing commits. For each author, we record the name, email(s) and commit frequency classification (defined below). We define a bug’s lifetime to be the time from the earliest commit which introduced the bug to the bug-fixing commit.
We compute each author’s commit frequency classification, based on the frequency of an author’s commits to a particular project, and author experience at commit time for each patch, based on the elapsed time between that author’s first commit to the project and the commit time.
via Francis the Mule via Marc Abrahams
Kommentare (11)