Improving the Internal Quality of Software through Reputation-based Gamification Von der Fakultat¨ fur¨ Mathematik, Informatik und Naturwissenschaften der RWTH Aachen University zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften genehmigte Dissertation vorgelegt von Diplom-Informatiker Christian Reinhard Prause aus Siegburg Berichter: Prof. Dr. Matthias Jarke Prof. Dr. Volker Wulf Tag der mundlichen¨ Prufung:¨ 21.3.2013 Diese Dissertation ist auf den Internetseiten der Hochschulbibliothek online verfugbar.¨ Abstract Zusammenfassung Developers are notorious for their dislike of writing in- Entwickler sind beruchtigt¨ fur¨ ihre Abneigung gegen ternal documentation. It has few value to them because das Schreiben von Dokumentation. Der personliche¨ its benefits are too far away in the future and distributed Nutzen hiervon liegt zu weit in der Zukunft und wird on the whole team, while the efforts of documenting mit anderen geteilt, wahrend¨ der Schreibaufwand auf are burdened on the individual himself. The resulting dem Einzelnen lastet. Das Ergebnis sind Phanomene¨ phenomena have names like free riding or tragedy of the wie Trittbrettfahren oder die Tragik der Allmende. commons. Software ist eine Ansammlung kodierten Wissens Software is an accumulation of encoded knowledge und ein Auffangbecken fur¨ Komplexitat.¨ Ihr Entste- and a collecting pond for complexity. Its development hungsprozess gleicht eher Forschung und Evolution als is more akin to research and evolution than to an agreed einem festen Weg mit klarem Ziel. Die gemeinsame Ar- path with an established goal. Multiple developers are beit mehrerer Entwickler wird von unterschiedlichsten engaged in an intricate joint endeavor, building on dis- Interessenten begleitet, und besteht aus Entdeckung, covery, invention and decision making, flanked by sev- Erfindung und Entscheidung. Um die Software an sich eral stakeholders. A developer must constantly learn laufend andernde¨ Anforderungen anpassen zu konnen,¨ and relearn the software to be able to adapt it to ever- muss ein Entwickler ihr Inneres standig¨ (wieder) er- changing requirements. Instead of being “soft” and easy lernen. Anstatt leicht anpassbar zu sein, ist Software to adapt, software is difficult to modify. If knowledge is schwer zu andern;¨ ihre Entwicklung ist daher teuer. not preserved in source code, wiki articles, and other doc- Wird das Wissen nicht in Quellcode, Wiki-Artikeln umentation, then software development becomes costly oder anderer Dokumentation wohl bewahrt, droht ein even up to the point of a total economic loss. wirtschaftlicher Totalschaden. This research presents CollabReview, which ad- Diese Arbeit prasentiert¨ CollabReview, das anstatt dresses the developers’ motivation to invest in internal strenge Regeln vorzugeben, die Motivation der Entwick- quality without strict regulation. It re-balances intrap- ler anspricht, in interne Qualitat¨ zu investieren. Es bee- ersonal cost-benefit considerations in favor of internal influsst intrapersonelle Kosten-Nutzen-Uberlegungen¨ quality using gamification. Personal reputation scores zu Gunsten interner Qualitat¨ mittels Spielelementen. for developers are calculated from ownership-based Dazu werden personliche¨ Reputationspunkte fur¨ En- responsibility and quality ratings for collaboratively twickler aus Qualitats-¨ und Zustandigkeitsinformationen¨ written software process artifacts. The scores are tied to von gemeinschaftlich entwickelten Software-Artefakten social games and rewards to make scores worthwhile to berechnet. Um die Punkte erstrebenswert zu machen, achieve. The implemented prototype of the CollabRe- sind sie an soziale Spiele und Belohnungen gekoppelt. view concept mines responsibility information from Der CollabReview Prototyp gewinnt seine Informatio- revision histories, and combines it with manual and nen aus Entwicklungshistorien, und kombiniert sie mit automated assessments of artifact quality. manuell und automatisch erzeugten Qualitatsreviews.¨ The CollabReview concept and prototype were eval- Das Konzept und der Prototyp von CollabReview wur- uated in several studies including an analytical con- den in Expertenanalysen, technischen Validierungen und cept evaluation, technical validations and field exper- Feldversuchen evaluiert. Letztere brachten den Prototyp iments. The latter deployed the prototype in knowledge in agilen, quelloffenen, verteilten Konsortial- und Wis- management, agile, open source or distributed consor- sensverwaltungsprojekten zum Einsatz. Die Beitrage¨ tium projects. It successfully amplified contributions to zur Wissensverwaltung konnten so erfolgreich gesteigert knowledge management wikis, and improved the read- und die Lesbarkeit von Quellcode verbessert werden. ability of source code. The results show that CollabRe- Die Ergebnisse zeigen, dass CollabReview zu besserer view leads to better internal documentation and quality interner Dokumentation und Qualitat¨ der Software fuhrt.¨ of the whole software. At the same time, it leaves devel- Gleichzeitig lasst¨ es Entwicklern die Freiheit, Qualitat¨ opers their freedom to neglect quality when necessary, wenn notig¨ zu vernachlassigen,¨ belastet sie nicht mit does not burden them with unnecessary additional ef- unnotigem¨ Mehraufwand, und hat folglich besonderen forts, and hence has particular value in self-organizing Wert in selbst-organisierenden Projekten mit schwacher project environments where code ownership is weak. Quellcode-Eigentumerschaft.¨ iii iv Contents 1 Introduction 11 2 Problem Scope: On the Quality of Software Process Artifacts 13 2.1 Introduction to Software Process Artifacts . 13 2.1.1 Software as collection of knowledge . 13 2.1.2 Software development as costly knowledge creation process . 15 2.1.3 Software process artifacts document created knowledge . 17 2.1.4 Source code and other documentation, and how to best make it . 20 2.1.5 Summary of software development as knowledge creation . 21 2.2 The Case for Internal Quality . 22 2.2.1 Source code as the project’s most valuable output . 22 2.2.2 Protecting the value in source code, and the cost of maintenance . 22 2.2.3 Why and where internal quality matters . 25 2.2.4 Summary of the importance of internal quality . 27 2.3 An As-is Analysis of Internal Quality . 27 2.3.1 The software crisis in literature . 28 2.3.2 Evidence of the problems in popular developer culture . 29 2.3.3 Interviews with Software engineering experts . 29 2.3.4 The Karakos EU project case study . 31 2.3.5 Karakos is not a black swan – EU project survey . 38 2.3.6 Diverse Own Experiences . 40 2.3.7 Summary . 44 2.4 Analysis of Problem Causes . 44 2.4.1 How people, processes and technology affect quality . 44 2.4.2 Resistance against new processes and technologies . 46 2.4.3 Economic goods and the tragedy of commons . 46 2.4.4 The tragedy of commons for internal quality . 47 2.4.5 Summary of origins . 50 2.5 Summary of the Problem . 50 v CONTENTS 3 State of the Art 53 3.1 Software Engineering . 53 3.1.1 Introduction . 53 3.1.2 Computer-aided software engineering . 54 3.1.3 Development methodologies . 56 3.1.4 Summary . 57 3.2 Software Quality . 57 3.2.1 The nature of quality . 58 3.2.2 Reducing internal failure cost with internal quality . 60 3.2.3 Quality management . 63 3.2.4 Summary . 66 3.3 Testing . 67 3.3.1 Map of testing . 67 3.3.2 Manual dynamic testing . 68 3.3.3 Automatic dynamic testing . 68 3.3.4 Manual static testing . 69 3.3.5 Automatic static testing . 70 3.3.6 Summary . 72 3.4 Mining Software Repositories . 73 3.4.1 Contribution, knowledge and ownership . 73 3.4.2 Determining contributors in evolving artifacts . 73 3.4.3 Concepts of contribution mining . 76 3.4.4 Software process artifact halo . 79 3.4.5 Information retrieval . 79 3.4.6 Summary . 81 3.5 Collaboration, Organization and Motivation . 81 3.5.1 Introduction . 81 3.5.2 Collaboration . 81 3.5.3 Organization . 84 3.5.4 Management and motivation . 86 3.5.5 Summary . 90 3.6 Comparable Works . 90 3.6.1 In ubiquitous computing . 90 3.6.2 In online collaboration . 91 3.6.3 In software development . 91 3.6.4 Summary of comparable work . 91 3.7 Summary . 92 vi CONTENTS 4 Thesis Statement 93 5 Design Process and CollabReview Concept 95 5.1 The Research Process . 95 5.1.1 The iterative process of this research . 96 5.1.2 List of requirements . 96 5.1.3 Details of the research iterations . 99 5.1.4 Summary of the research process . 105 5.2 The Computational Model . 105 5.2.1 Modeling software process artifacts . 105 5.2.2 Importance weight of software process artifacts . 107 5.2.3 Responsibility of contributors for software process artifacts . 107 5.2.4 Quality of software process artifacts . 109 5.2.5 Putting it together to karma scores . 111 5.2.6 An example of karma scores . ..