EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2019 Line of Code Software Metrics Applied to Novice Software Engineers MICHAEL PALMÉ FELIX TOPPAR KTH SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP Line of Code Software Metrics Applied to Novice Software Engineers Palm´e,Michael Toppar, Felix [email protected] [email protected] June 2019 Abstract In the world of modern software engineering, there are certain metrics used to measure size and effort of projects. This provides insight to how engineers work, however when it comes to novice engineers there is little to no documentation. Without enough documentation this becomes a problem when trying to make predictions on projects involving novice software engi- neers, since there simply is not enough previous work on the area involving novice software engineers. The problem is that there is very little research available when it comes to how novice software engineers efficiency compares to more experienced software engineers. This makes it difficult to calculate predictions on software projects where novice engineers are involved. So how do novice engineers distribute their time and effort in a software development project? The purpose is to find out how the time is distributed in a workplace involving novice software engineers. Further is to learn more of the differences between how novice and experienced software engineers distribute their time and effort in a project. The goal of this thesis is to improve the understanding of how novice software engineers contribute to a software project. In this work, a case study has been done with two novice engineers at a workplace in order to learn more about how novice engineers contribute to a software project. In this case study, a quantitative research method was adapted using the Line of Code software metric to document how the novice engineers distributed their time. The results of the case study showed that the two novice engineers spent far more time coding than planning and that they wrote code faster than the average experienced engineer. Abstrakt I den moderna mjukvaruingej¨orsv¨arlden s˚afinns det vissa metriker som anv¨andsf¨oratt m¨atastorleken och anstr¨angningenav ett projekt. Med detta s˚af˚arman insikt om hur ingenj¨orerarbetar, men n¨ardet kommer till nyut- bildade mujukvaruingenj¨orers˚asaknas det dokumentation. Utan tillr¨ackligt med dokumentation s˚ablir det snabbt ett problem n¨arman f¨ors¨oker planera projekt som involverar nyutbildade mjukvaruingenj¨orer,detta eftersom att det saknas information i omr˚adetn¨ardet g¨allerjust hur nyutbildade mjuk- varuingenj¨orerarbetar. Problemet ¨aratt det finns v¨aldigtlite unders¨okningtillg¨anglign¨ardet kommer till hur effektiva oerfarna mjukvaruingenj¨oreri j¨amnf¨orelsemed mera erfarna ingenj¨orer.Detta g¨ordet sv˚artatt ber¨aknaoch f¨orutsp˚ahur mjuk- varuprojekt utvecklas n¨aringenj¨orerna¨armera oerfarna. S˚ahur f¨ordelar oerfarnba mjukvaringenj¨orersin tid och var finns det st¨orstaanstr¨angningen vid ett arbete i ett mjukvaruprojekt. Menigen med detta arbete ¨aratt ta reda p˚ahur tiden som l¨aggsp˚aett mjukvaruprojekt distrubieras p˚aen arbetsplats med nyutbildade mjukvaruin- genj¨orer. M˚aletmed detta arbete ¨aratt f¨orb¨attraf¨orst˚aelsenang˚aendehur nyut- bildade mjukvaruingenj¨orerbidrar till ett mjukvaruprojekt. I det h¨ararbetet s˚ahar en fallstudie gjorts med tv˚astycken nyutbildade mjukvaruingenj¨orerf¨oratt unders¨oka hur nyutbildade ingenj¨orerbidrar till ett mjukvaruprojekt. Fallstudien f¨oljerdessa tv˚aingenj¨orerp˚aen arbet- splats d¨aren kvantitativ unders¨okningg¨orsmed hj¨alpav Line of Code mjuk- varumetriken som anv¨andsf¨oratt dokumentera hur ingenj¨orernaf¨ordelade sin tid p˚aarbetsplatsen. Resultaten av fallstudien visade att dessa tv˚anyutbildade ingenj¨orer spenderade mycket mer tid ˚atkodande ¨an˚atplanerande, och att de skrev kod snabbare ¨anden genomsnittliga erfarna ingenj¨oren. Acknowledgements We would like to extend our gratitude to Qopla, who let us work with them at their office during the duration of this study. It was the first time either of us had worked in a professional software engineering environment. As such, it was very educational and we are now optimistic about the future and our post-graduation endeavors. Contents 1 Introduction 4 1.1 Background . .5 1.2 Problem . .6 1.3 Purpose . .6 1.4 Goal . .7 1.4.1 Benefits, ethics and sustainability . .7 1.5 Collaborators . .7 1.6 Delimitations . .8 1.7 Outline . .8 2 Metrics in Software Engineering 10 2.1 Size . 10 2.1.1 Line of code . 11 2.2 Activities . 12 2.3 Effort . 13 2.4 Related work . 13 3 Research Method 18 3.1 Research strategy . 18 3.2 Action research . 18 3.3 Research phases . 19 3.3.1 Literature study . 19 3.3.2 Preparatory work . 19 3.3.3 Programming . 19 3.3.4 Conclude and analyze . 20 3.4 Respondents . 20 3.5 Validation threats . 20 2 4 Definitions for Lines of Code, Activities in the Workplace, and Effort 22 4.1 Lines of code . 22 4.2 Activities in the workplace . 26 4.3 Effort . 33 5 Results 34 5.1 The data . 34 5.2 Analysis . 35 6 Final Discussion and Future Work 38 A The Original Definition of a Line of Code 42 B The Original Activity List 44 3 Chapter 1 Introduction Engineering implies measuring, this is a fact. Let us think of a successful business. In order for the business to be successful the business needs to max- imize profit. One way for the business to do this is by constantly keeping track on which products are selling and which are not. Based on the numbers the business can then determine which products to invest in. Another way for the business to maximize profits is by monitoring and measuring changes in the revenue when increasing or decreasing the number of employees that the business have. These are two of an almost countless amount of measure- ments a business can perform in order to be successful. Let us hypothetically imagine another business that is struggling, be- cause they fail to make smart decisions. Now, this business is not lazy, the employees work even longer hours than in the more successful business. So how can this be? The answer might seem ridiculous, but in this case the reasons are that the failing business can not keep track on which products are selling and which are not. Furthermore the business can not figure out the optimal number of employees to have. In short the business have been slacking when it comes to logging the sales-data. Therefor this struggling business are missing measurements needed in order to be able to compete with the more successful business. The two text segments above noted the importance of measuring within a business. But this importance also applies to engineering, in particular software engineering. In software engineering it is important to minimize the time it takes to produce a production quality line of code. Doing this 4 allows a software business to finish projects faster and thereby increasing the profit. One way is to find circumstances in which an employee can produce a higher amount of lines of codes. These circumstances can then be replicated making the employee more efficient. There exists many different methods and metrics on how to achieve this [13]. A popular metric and the metric this bachelor thesis will be focusing on is called The Line Of Code (LOC) software metric. However this metric lacks studies, reports and data when it comes to its application on to novice software engineers, which makes the measurements harder to conduct. One way to think about it, is to reflect back to the first two text segments. Imagine that the struggling business employs only novice engineers and is now falling behind because of the lack of data when it comes to the application of the LOC metric. While the successful business employs no novice engineers and is therefor gaining an advantage because of the larger amount of data available on the application of the metric. 1.1 Background In most businesses, it is desirable to measure as much as possible within a company in order to keep track of efficiency and other attributes. When it comes to software engineering it is relevant to measure the size of software projects. But how can this be measured? As it turns out, the most popular way of measuring size of a software project is to count "lines of code". To the reader who is unfamiliar with the world of programming this might seem like a very reasonable thing to do, and it definitely made sense back in the 1970s when the metric "lines of code" was invented. This was during a time when programmers used punch cards to input their code (where one card usually corresponded to one line of code), and "line-oriented" programming languages were the status quo. However in modern times it is actually a quite vague and tricky metric, since there are so many definitions of what could count as a line of code (as well as the total amount of lines of code being dependant on programming language, frameworks used, and type of software system being programmed). Despite this, counting lines of code remains the standard due to no better option existing, and it is certainly a better metric than no metric at all. 5 Programming speed and time distributed by the workers are also impor- tant statistics to document. Given that a definition for the size of a software project exists (lines of code), calculating the programming speed of a worker only requires someone to document the time spent coding, and then divide the size with the time spent. Programming speed could also be described as ”effort”.