Readability Studie - Entwicklertagebuch

23. Oktober 2013


Sehnsüchtig warten die Teilnehmer meiner Studie schon auf deren Ergebnisse - bisher hatte ich es noch nicht geschafft, diese vorzustellen - zumindest bei denen, denen ich ebendies versprochen hatte. Die Studie fand im Rahmen meines empirischen Praktikums - kurz: EMPRA - statt. Es handelt sich dabei also noch NICHT, wie von vielen fälschlicher Weise angenommen, um meine Bachelorarbeit, allerdings dient die Studie der Vorbereitung ebendieser.

Für die hohe Latenz entschuldige ich mich aufrichtig und möchte mich herzlich bei den Teilnehmern bedanken - ohne euch hätte ich es nicht schafft! Danke, liebe Teilnehmer, dass ihr mir geholfen habt

Ich habe viel durch die Studie gelernt und daher einiges zu erzählen. Inhaltlich ist erst mal spannend zu berichten, worum es ging und was da gemacht wurde - die Kurzversion. Den einen oder anderen mag aber vielleicht auch das Making-Off und die Theorie interessieren. Aktuell liegen nur die "Uni"-Ergebnisse vor. Der Bericht beinhaltet beispielsweise Details zu den verwendeten statistischen Methoden, allerdings ist mir klar, dass diese nicht für jeden unmittelbar interpretierbar sind. Daher werde ich, so schnell ich kann, eine Version der Ergebnisse schreiben, die auch Nichtwissenschaftler verstehen.

Ergebnisse

In einem Satz

Durch explizite Bezeichner (customer, request, repository, etc.) lassen sich, gegenüber Abkürzungen (acm, req, rep, etc.) und einzelnen Buchstaben (a,c,s, etc.) Fehler in Quellcode um zwischen 10 und 25% schneller (und präziser) finden.

Details

Die Ergebnisse der Studie lassen sich am Besten durch mein Poster erfassen. Das Poster wurde, nach dem die Studie durchgeführt worden war, im Rahmen des Praktikumskongresses erstellt. Genaueres kann dem Studienbericht (Pdf) entnommen werden. Dieser beinhaltet eine konkretere Herleitung und eine genauere Diskussion meiner Theorien, sowie - wahrscheinlich - viele, viele Rechtschreibfehler.

Interessant ist vielleicht noch eine kleine Beschreibung des Prozesses. Immerhin ist es meine erste Studie gewesen und hoffentlich nicht meine letzte.

Hintergründe

Ich habe die Software zur Erhebung selbst entwickelt und möchte bald ihren Source Code veröffentlichen. Leider ist sie in einem - für meinen Geschmack -furchtbaren Zustand. Sie kommt mit wenig aus, aber beinhaltet viele Quirks und Eigenarten, die vielleicht nicht ganz nachvollziehbar sind.

Umsetzung

Als Server verwendete ich Flask , den ich auf Heroku hostete. Die Datenanbindung wurde über MongoHQ bewerkstelligt. Die Hauptarbeit steckte im Client. Diesen baute ich mit Twitter Bootstrap und viel händischem JavaScript. Ich evaluierte mehrere Frameworks und entschied mich dann für eine Eigenentwicklung für den Client. Die Fragebögen tippte ich in plain HTML.

Positiv: NoSql

Angenehm war dabei, dass die HTML Forms in Flask einfach als Python-Dictionaries ankamen, die ich 1:1 an MongoHQ als Json/BSON Dokumente weiterreichen konnte. Dadurch bestimmte die HTML Seite, welche Daten ich erhalten möchte - an einer einzigen, zentralen Stelle. So angenehm lässt es sich mit keinem OR/M arbeiten und ich glaube, dass NoSQL für den Einsatz höchst angemessen, aber mindestens ausreichend war.

Positiv: Bootstrap

Ich war sehr "geflashed" von Bootstrap. Es hat mir unendlich viel Arbeit leichter gemacht. Zuvor hatte ich nicht verstanden, dass BS auch viel JavaScript magic mitbringt. So entdeckte ich bei der Entwicklung, dass durch einbinden der mitgelieferten .js Datei bestimmte Funktionen verfügbar wurden, die ich durch ´´´data- ´´´ Attribute bestimmter HTML(5)-Tags aktivieren konnte. Ein Segen.

Fehlentscheidungen

Blöd war eigentlich nur das HTML für die Fragebögen. Ich hatte angefangen, eine Fragebogen-DSL zu schreiben. Leider kam der Parser nicht zum Einsatz, weil ich bei seiner Entwicklung das Gefühl hatte zu prokrastinieren und mich zwang, mich mehr auf die eigentlichen Daten zu konzentrieren, anstatt mal wieder ein Datenerfassungsframework zu bauen. Ich handelte damit - gezwungener Maßen - gegen das Motto von Terence Parr (der Typ der Antlr gebaut hat):

"Why program by hand in five days what you can spend five years of your life automating?"

Persönlich

2011 kam ich an die Uni Heidelberg und begann dort mein Psychologiestudium. Dieses war zunächst inhaltlich sehr allgemein gehalten, jedoch hatte ich das Bedürfnis, konkrete Fragestellungen zu beantworten. Das Empra war der Raum für eigene Ideen und somit die erste Chance, eine Studie zu einem von mir definierten Thema zu machen. Leider kam es da zu dem "Drei Stooges Syndrom" - die Blockade die entsteht, wenn alles auf einmal raus muss.

![Three Stooges](/static/images/threestooges.jpg) Auch als K59.0 im ICD-10 zu finden. ([src](http://kjel.blogsome.com/images/threestooges.jpg))

Daher dauerte die Studie länger als geplant und dadurch entstanden auch die langen Pausen zwischen der Registrierung, der eigentlichen Studie und der Auswertung. Aber nun sind die Wogen geglättet und erste Ergebnisse liegen vor.

Diskussion

Viele Daten wurden ausgewertet, aber einige Daten wurden aus Zeitgründen einfach ignoriert. Das Semesterende nahte und die Studie musste beendet werden, deswegen finden sich nicht alle gewonnenen Kenntnisse im Studienbericht dokumentiert. Allein das bereits Erhobene ist ausreichend, um eine kleine Bachelorarbeit zu füllen und verschiedene Folgestudien sind bereits in Sicht.

Und für die brauche ich sicher bald wieder Teilnehmer :)