Technical Debt as a Core Software Engineering Practice
Abstract
Over the years, we worked with a lot of customers who have gone through issues in terms of legacy modernization, agile adoption, how much architecture is enough?, how do you change technology as things change?, and all that. Across those different kinds of customers and different kinds of challenges, one thing remains constant: It is that inability to be able to articulate what actually accumulates as it stays on the system and then what actually could stay. For example, Do I really need to upgrade the legacy? Do I really re-architect? And how do I really make that tradeoff decision? At the end of it, it is really about understanding both design decisions as well as your business decisions. These concepts have been around for a while about maintainability, evolution, and what not. But once you express them in terms of financial concepts and talk about them in terms of those tradeoffs, it starts resonating. That is how my team and I started looking into technical debt as both a communication mechanism but also as a way to combine multiple research challenges together. That is how we embarked on the project. One of the things that we actually became very pleasantly surprised at, a lot of industry as well as researchers are quite engaged because it resonates with them. It expresses their problems in their perspective. In 2010, we had a small gathering of researchers articulating what might be actually some of the issues. Since then, we have actually had a growing body of work as well as collaborative groups that have been working on the subject.
Document Details
- Document Type
- Technical Report
- Publication Date
- Jan 01, 2021
- Accession Number
- AD1145833
Entities
People
- Ipek Ozkaya
- Suzanne Miller
Organizations
- Carnegie Mellon University