Context. Architecture maintainability smells indicate software quality problems and suggest necessary architecture refactorings. However, there are numerous names for a single smell, including synonyms and subclasses, and the number keeps increasing. This situation leads to confusion and difficulty in identifying the underlying problems. Objective. To address this challenge, we want to organize the existing smells. Method. We collect smell names through a systematic literature review, followed by a four-step data analysis leading to a taxonomy of maintainability smells, comprising smell characteristics, categories, detection methods, and causes. Results. We found 549 architecture smell names in 189 references, from which we identified 318 maintainability smell names. We derived the distinguishing characteristics and reduced the list to 19 essential maintainability smells. Conclusions. Our taxonomy provides an overview of essential maintainability smells, making future research and discussions more manageable. Moreover, the identified synonyms make existing research comparable, and the characteristics, causes, and detection methods provide a framework for classifying future smells.

Many software projects suffer from architecture erosion and architecture technical debt. One challenge is to identify affected parts and prioritize them for refactoring. Architecture smells are indicators of potential architecture technical debt, but architecture smells are ambiguous and their impact is not always clear. To address this, we have built a knowledge base that improves understanding of architecture smells and identifies violated software design principles and affected quality attributes. The design principles help our understanding of what causes architecture smells, while the impaired quality attributes represent the consequences. We conducted a systematic literature review to identify these relations and built an architecture smell ontology. This ontology provides a knowledge base that architects can use to prioritize the smells according to the project's individual quality goals.

Technical Debt (TD) is a metaphor for technical problems that are not visible to users and customers but hinder developers in their work, making future changes more difficult. TD is often incurred due to tight project deadlines and can make future changes more costly or impossible. Project Management usually focuses on customer benefits and pays less attention to their IT systems’ internal quality. TD prevention should be preferred over TD repayment because subsequent refactoring and re-engineering are expensive. This paper evaluates a framework focusing on both TD prevention and TD repayment in the context of agile-managed projects. The framework was developed and applied in an IT unit of a publishing house. The unique contribution of this framework is the integration of TD management into project management. The evaluation was performed as a comparative case study based on ticket statistics and two structured surveys. The surveys were conducted in the observed IT unit using the framework and a comparison unit not using the framework. The first survey targeted team members, the second one IT managers. The evaluation shows that in this IT unit the TAP framework led to a raised awareness for the incurrence of TD. Decisions to incur TD are intentional, and TD is repaid timelier. Unintentional TD incurred by unconscious decisions is prevented. Furthermore, better communication and better planning of the project pipeline can be observed. We provide an insight into practitioners’ ways to identify, monitor, prevent and repay TD. The presented framework includes a feasible method for TD prevention despite tight timelines by making TD repayment part of project management.