Interview with Ipek OZKAYA (SEI) on Technical Debt, Agile and Architecture
When thinking about technical debt of applications, many questions come in our minds: Should we take architecture’s defects into account to quantify the debt, as we already do with code defects? Can Agile developments generate an unintended debt? Ipek OZKAYA, a senior member of the technical staff at SEI, kindly answered to our questions.
According to your experience, what would the best definition of Technical Debt? Do you think the metaphor has to remain just symbolic (and not intended to be measured)?
Taking on technical debt should be a strategic decision; therefore the definition should clearly emphasize strategy. Steve McConnell in a recent webinar described this well, and I find his definition most succinct and useful:
“Technical debt is a design or construction approach that’s expedient in the short term, but that creates a technical context in which the same work will cost more to do later than it would cost to do now.”
The aspects of the metaphor (what is being borrowed, the interest to be paid, and the payback terms) help clarify the tradeoffs being made. In essence, increased attention to understanding technical debt reflects the continuing inability to manage maintenance costs and handle software evolution. From that perspective, I do think there is merit in investigating how to be more clear about implications of technical debt. Whether this means precise measurement or other quantification methods depends on the kinds of results we will see from research and the efforts of the tool vendors.
Systems that are in operation for a long time and that go through technology upgrades do also naturally accumulate technical debt as a result of software aging. From a software-sustainability perspective as well, there is value in quantifying further what debt means.
The notion of “technical debt” communicates clearly the unwanted and unintended consequences of degrading quality and accumulation of interest to be paid. As a result, it has gained significant attention. Unfortunately, though, the term has started to be used to refer to any unwanted effect in a software-development project. I find this worrisome, as it encourages justification of bad software engineering practices. Technical debt represents the chasm between software sustainability (evolution and maintenance) and the expedient short-term decisions to borrow resources.
The awareness (buzz?) around technical debt seems to have risen along with the emergence of Agile these last years. In your opinion, what are the links between both? Are non-agile teams not caring about technical debt?
Everyone is caring about technical debt, whether developing in an Agile or non-Agile context. I observe two reasons why the awareness seems to be more with those teams practicing Agile development, especially Scrum.
- With the increased success of Agile development in IT environments especially, more organizations and domains have started to adopt Agile or Agile-like techniques. Unfortunately, if the adoption has not been well structured, teams often jump into feature development, forgoing development that supports infrastructure. When such is the case, these teams struggle the most with unintentional technical debt.
- In Scrum environments, many teams struggle with how to estimate and collect the story points for technical-debt-related tasks. This has resulted in both confusion and discussion, which have raised awareness.
However, it would be wrong to associate technical debt with only an Agile-development context. We observe organizations struggling with technical debt that include those developing safety-critical systems in phase-based, waterfall development as well as in government organizations trying to move to more iterative software-development environments.
Is there a project within SEI to normalize the measurement of the technical debt of a software?
At the SEI we have a current project where we are investigating how to analyze degrading quality for the quality attribute requirements of modifiability and extensibility in terms of the potential rework they may require. Our approach to system design and development is rooted in aligning the business goals of the system with its structure and behavior. Similarly, for understanding how to quantify technical debt, we are investigating how to align quality attributes with relevant quality measures at the architecture level quantitatively . You can read more about this work at http://blog.sei.cmu.edu/post.cfm/developing-an-architecture-focused-measurement-framework-for-managing-technical-debt
You’ve probably heard of SQALE or CISQ, which provide methods to measure technical debt. In your opinion, is it sufficient to measure code debt with a simple formula (aggregation of unit remediation costs, for SQALE for example) or do we need a more complex formula to compute the precise technical debt of an application?
Understanding the quality of code, of course, provides some insights; however, we observe over and over again that the kind of debt that is hardest to deal with is often not the kind that is detectable by looking at code only. The motivation behind efforts in quantifying technical debt is to be able to devise a payback (in other words, rework) strategy. For example, it is not possible to detect many runtime performance issues just by looking at code or at a static-module view of the architecture. Quantification is important from the perspective of understanding the impact of what needs to change in the system. Understanding technical debt, however, also involves mapping to the business needs and the tradeoffs that involve the time perspective.
Should we consider architecture defects (ie: a component calling another one directly, instead of using the layer designed for) as being a part of technical debt, or should we dissociate these two kind of debt (code debt and architecture debt). Which stakeholder should have to manage the debt: dev teams, architect, product owner, scrum master?
Architectural defects definitely need to be considered. The reason technical debt is a big issue is that it creates (often unwanted and unplanned-for) rework cost for the future. Architectural defects are often hardest to rework, especially if caught too late. However, the design rules for each project will be different. While there are universal “good design” notions that architectural patterns, for example, encapsulate, the implementations of these in each project will vary.
Consequently, technical-debt management should be owned by multiple stakeholders. The input of both the technical members of the development team and the business-savvy stakeholders is needed, especially in coming up with decisions involving reducing or going into technical debt.
Are rapid agile developments possible, without disturbing the stability of architecture (and ideally while taking the opportunity to improve it)? Could you present some tactics that teams can use?
Agile development and having a sound and stable architecting approach are not mutually exclusive. Our interactions with teams and individuals in the roles of Scrum master, developer, project manager, and architect on projects from organizations that develop embedded real-time software, cyber-physical systems, and IT systems have shown us that successful projects are those that can take advantage of both Agile development and architecture centricity. It is somewhat trivial when one team is developing the system. It becomes harder when multiple teams need to be orchestrated. Some tactics that become handy are:
- aligning feature-based development and system decomposition;
- creating an architectural runway;
- using matrixed teams.
These tactics, which can also be used in combination, are further explained in our recent paper http://www.crosstalkonline.org/storage/issue-archives/2012/201205/201205-Bachmann.pdf
About Ipek OZKAYA
Ipek Ozkaya is a senior member of the technical staff at SEI and works to develop empirical methods for improving software development efficiency and system evolution with a focus on software architecture practices, software economics, and requirements management. Her latest publications include multiple articles on these subjects focusing on agile architecting, dependency management, and architectural technical debt. Ozkaya serves on the advisory board of IEEE Software.