Computer Science Research

Technical Debt

The Technical Debt metaphor describes the tradeoff between

  • getting a software release "out the door" as quickly as possible and 
  • applying all the good processes to assure the best possible software quality. 

In the first case the software project might run into debt and one will have to pay interest in later releases, e.g. in form of lower maintainability, portability, security etc. In the second case, one might end up with better software, but miss an important customer deadline or potentially release a product too late into the market. Technical Debt research aims at quantifying and communicating this tradeoff in order to make a more informed decision on when it is financially beneficial to take on debt, and when it is not.

 

Truck Factor Measurement

The Truck Factor has been defined by the agile community as "the number of developers that can get hit by a truck, before your project is in trouble". Certainly, I do not wish any developer to get hurt in such an accident. However, the idea behind this concept is to find a metric for team volatility, that is how easily a software projects can be brought to halt by the loss or change of personell. In many projects only a single developer has extensive knowledge, and not rarely is this knowledge used as job security. Actively measuring and managing team volatility helps to reduce projects risks, and to spread knowledge among the development team. In 2010, with the help of reseachers from Hanover, I proposed a method to estimate the truck factor by mining software repositories. Since then, multiple follow-up publications by other researchers have investigated its usefulness and proposed further improvements.

 

Process Conformance Testing

Software development processes and practices are not rarely perceived as the "necessary evil" by software developers, designers and testers. On the one hand, strict processes allow for more replicable results across projects and provide proven recipes. On the other hand, software processes might limit creativity and flexibility, and create unnecessary overhead if not carefully tailored towards the team and project context. 

 

Understanding when a process cannot be followed by the development team is an important step for finding ways to improve the process in future. My research in process conformance testing (a.k.a. process compliance testing) aims at identifying problem hotspots in processes by mining software repositories, task tracking systems, and other existing data sources.