Technical debt analysis is used to detect problems in a codebase. Most technical debt indicators rely on measuring the quality of the code, as developers tend to induce recurring technical debt that emerges along with evolution cycles. This debt can emerge when project pressure leads to process deviations, for instance. In agile methods like Scrum, such deviations are commonly known as ScrumButs (like Scrum but …), which can be considered as a form of process debt. In this paper, we investigate two recurring signs of process debt (i.e. code smells and anti-patterns) caused by Scrumbuts. Our contribution investigates typical ScrumBut practices found in agile projects in one company and we report the relationships found between problems in code and ScrumBut issues. Our findings identify three types of ScrumButs, their root causes, and how these relate to concrete code smells and anti-patterns.

Technical debt has become a common metaphor for the accumulation of software design and implementation choices that seek fast initial gains but that are under par and counterproductive in the long run. However, as a metaphor, technical debt does not offer actionable advice on how to get rid of it. To get to a practical level in solving problems, more focused mechanisms are needed. Commonly used approaches for this include identifying code smells as quick indications of possible problems in the codebase and detecting the presence of AntiPatterns that refer to overt, recurring problems in design. There are known remedies for both code smells and AntiPatterns. In paper, our goal is to show how to effectively use common tools and the existing body of knowledge on code smells and AntiPatterns to detect technical debt and pay it back. We present two main results: (i) How a combination of static code analysis and manual inspection was used to detect code smells in a codebase leading to the discovery of AntiPatterns; and (ii) How AntiPatterns were used to identify, characterize, and fix problems in the software. The experiences stem from a private company and its long-lasting software product development effort.

We present the work of establishing an integrated environment that facilitates architecture design, reconstruction, and maintenance in the entire life cycle of a software product line. This architecting environment (ART environment) has been used in modeling and analysis of both the designed platform architecture model and the reverse-engineered product implementation architecture models of different releases in a big product line of Nokia mobile terminals. ART environment comprises tools for architecture model validation, architecture model analysis and processing, and reverse architecting. The ART environment fits the current software development process inside Nokia, and is integrated with the design and documentation tools that have already been used by Nokia software architects. UML, after being customized with UML profiles for architecture design, is used as the architecture modeling language in ART environment.