An Approach to Non-Invasive Cost Accounting Saulius Astromskis, Andrea Janes, Alberto Sillitti, and Giancarlo Succi Free University of Bozen/Bolzano, Center for Applied Software Engineering, I-39100 Bolzano, Italy Email: saulius.astromskis@stud-inf.unibz.it, {ajanes, asillitti, gsucci}@unibz.it Abstract—Cost accounting is an essential instrument to mea- sure the efficiency of organizations in creating value for the market. Unfortunately, according to our experience, software development teams do not make use of cost accounting. They rarely know how much costs their projects generated, where resources could be saved, and which working habits potentially reduce costs. We assume that this is because developers and project managers think that it does not pay off to obtain cost accounting information to provide decision support. This paper proposes a non-invasive approach to cost-accounting, i.e., an approach that does not require any effort to collect cost- accounting data. Using the here described approach, software development teams can measure their software development costs, understand what causes them, and react to reduce them. I. MOTIVATION FOR NON- INVASIVE COST ACCOUNTING According to the dictionary, cost accounting is the “theory and system of setting up, maintaining, and auditing the docu- mentation about the cost of items involved in production [1].” In other words, by the term “cost accounting” we mean a set of practices that we use to get a complete and true picture of what we spend to produce a certain good. Cost accounting helps to optimize the production process: by understanding what we spend to obtain a certain output we find out which costs we have to reduce to increase the overall efficiency. Cost accounting does not only keep track of the costs, it serves different purposes as well, for example to calculate a minimum price that covers the production costs or to gather data about the possible consequences of decisions [2]. It also attributes the identified cost to a cost-item, i.e., to what caused the costs. This is not a straightforward step, as we will see below. By linking costs to a cost-item, we can later evaluate if the costs generated by the cost-item are needed in the current form or if it would pay off to change something, for example to buy the produced cost-item from an external vendor. The precision with which we are able to assign costs to their cause increases our possibilities to optimize the production process. While in traditional production companies cost accounting is a strategic instrument to understand and reason about how to optimize production, according to our experience, cost ac- counting is typically not practiced within software production, at least not as precise as it occurs in traditional production companies. Traditional production companies collect data about the costs of raw materials, their use to produce the desired prod- ucts, the adopted technologies and processes, the deterioration of production materials, and so on, to get a precise picture of the costs that are generated during the production process. For example, a cost accountant working for a car producer can tell you how much a certain part of the car costs, without asking an engineer. The accountant has already collected such information and uses it to reason about how to optimize the production process. In a software development company, a cost accountant (if such a person exists) does not know the costs of a feature in their software and therefore does not use this information to improve efficiency in future projects. One reason for this discrepancy might be that software development is in fact development and not production [3]: software “production” has a very high degree of variability. Altogether, the software discipline is evolutionary and experi- mental [4], not as repetitive as a production process. It is often simply not possible to find the same activity executed several times, so it is hard to collect data to analyze it statistically [3]. The minimum amount of cost-accounting an organization typically does, is collect the amount of time developers spend for development, assigning the entire project they are currently working on to the time spent. It is reasonable to collect the development time since development costs are mainly determined by labor costs [5], [6]. Compared to the labor costs, the hardware costs can be (typically) neglected. Therefore it is enough to collect the time spent during a project and to multiply the result with the wage per time unit to obtain the costs. This allows companies to evaluate if a project paid off or to compare projects with similar costs. Unfortunately, tracking costs as described on the project level is not enough to answer typical questions that managers have, such as: • How much did an additional feature increase the development costs? • How expensive is it not to have anyone that knows HTML 5? • Why did our last product cost so much to produce? • Did we charge a client enough for the additional task? • Which types of features cost us the most? • Which skills should the team improve to increase efficiency? To answer these questions we would need to know how developers spend their time, that is, which parts of the code they where editing, which documents they where modifying, and so on.