For each instance of technical debt, the identification, assessment, and optimal route of governance between short- and long-term yields is unique . Commonalities do, however, exist. One of these is the ways with which technical debt is accumulated for the project. McConnell  identified intended (i.e. strategic) and unintended (i.e. accidental) accumulation which describe the two variations of the immediate situation wherein technical debt is accumulated. Arguably, however, there is also a third way which is delayed accumulation.
All software products are static. That is, after they have been developed, prior to being developed again, they remain in the exact same state (formalized for technical debt by Schmid in ). The environment around them, however, is dynamic. Technologies, people, organizational structures and processes change. All these and many others can be seen to have a link back to the static software product. As an explicit example, continued updates to a technology that is used to implement a software product: here the software product, for which development has stopped, does not abide to the latest version of the technology, and it becomes detached from the environment’s assumptions as they are no longer delivered via the technology’s updates. Hence, when the development is continued for this software product, we note that it has accumulated technical debt in a delayed fashion as current assumptions do not apply for it.
From the management perspective, there is a considerable difference between immediate and delayed accumulation. Immediate accumulation is affected mainly by matters that reside within the producing organization and its project. We may look into altering strategies and implementing new processes to affect the management of immediate, intended technical debt. Management of immediate, involuntary debt is often more indirect. For example, implementation and design quality issues often arise from practitioners having communication issues or being unaware of all applicable best practices. In these scenarios exercises to enhance social togetherness and focused training, respectively, can be utilized.
As per the previous description of delayed technical debt accumulation, its management is not limited to the producing organization only. Rather, the whole environment affects it; something that is impossible to subject to management and must be accepted to cause problems in the future. Within the fault management domain, efforts in this area are categorized under fault tolerance. Within the software development and maintenance domain, arguably, this is very close to legacy software management.
Legacy software has a variety of definitions, but it generally captures software artifacts which can not be subjected to the same maintenance and management efforts as newly created artifacts . In practice, these are often implementation artifacts which are old, undocumented and/or untested, and for which the original developer is no longer available–either a new team has taken over in the organization, or the implementation has been acquired from somewhere else. If we consider delayed technical debt accumulation to capture inoptimalities that emerge due to the environment progressing around a static software product, we could argue that legacy software is a very close match to it.
As an effort to shed light into the accumulation and composition of technical debt that software organizations face today, and, especially, to probe the close relation of delayed technical debt accumulation and legacy software further, we conducted a practitioner survey. This survey was administered as a web-based questionnaire in Brazil, Finland, and New-Zealand. We captured a total of 184 responses from a diverse set of respondents using both agile and traditional development methods in which the practitioners assumed several roles ranging from developers to managers and client representatives. We have discussed results of the Finnish survey in more detail before  while a forthcoming article reviews the multi-national results. The multi-national set captured 69 descriptions for a concrete technical debt instance. Let us look at the distribution captured for the instances’ origins.
Figure 1: Origins of technical debt instances (N=78 as multiple origins were indicated for some instances)
We see from Figure 1 that over 75% of captured technical debt instances have indicated origins in software legacy. Whilst acknowledging that there is a number of limitations affecting for example the results generalizability, using this distribution as a basis, we would like to discuss the interplay of technical debt and legacy further.
It is evident that there is a strong connection between technical debt and legacy as most technical debt instances are affected by it. Hence, technical debt could be seen to benefit from integration of legacy software management procedures, as this field has a very established status. However, there are matters that should be explored when legacy software methods are integrated into technical debt management. Firstly, is legacy software, as per the close similarity, only a component of delayed technical debt accumulation? Arguably not, as the overall current state of the software product–to which legacy can be counted to–has an effect on technical debt accumulation and management .
Second, legacy software is generally a negative term for “derelict code” while technical debt implies pursuing asset management functions for inoptimalities in varying software artifacts. Reviewing Figure 1, one identifies that there is a potential danger in legacy being re-branded under the more favorable technical debt concept. Here, the asset management possibilities are left unexplored if legacy is not diligently converted into technical debt instances enabling full management. Noting the unobtrusive nature of legacy software, this is not an easy task to do, and having technical debt instances with varying levels of accuracy is bound to deteriorate technical debt management efforts overall.
Either way, as per the limited view provided by our survey, legacy is a very close companion of technical debt, and we should pursue narrowing the gap between these fields. While total control over technical debt is extremely challenging to ascertain, finding that technical debt management is the key to sustainable and efficient software development should still motivate us to pursue it.
 N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya et al., “Managing technical debt in software-reliant systems,” in Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research. ACM, 2010, pp. 47–52.
 S. McConnell, “Technical debt,” 10x Software Development Blog,(Nov 2007). Construx Conversations. URL= http://blogs. construx. com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx, 2007.
 K. Schmid, “A formal approach to technical debt decision making,” in Proceedings of the 9th International ACM SIGSOFT Conference on Quality of Software Architectures. ACM, 2013, pp. 153–162.
 M. Feathers, Working effectively with legacy code. Prentice Hall, 2004.
 J. Holvitie, V. Lepp¨anen, and S. Hyrynsalmi, “Technical debt and the effect of agile software development practices on it-an industry practitioner survey,” in Sixth International Workshop on Managing Technical Debt. IEEE, 2014, pp. 35–42.
 A. Nugroho, J. Visser, and T. Kuipers, “An empirical model of technical debt and interest,” in Proceedings of the 2nd Workshop on Managing Technical Debt. ACM, 2011, pp. 1–8