On Technical Debt http://www.ontechnicaldebt.com Online Community Tue, 08 Apr 2014 13:40:09 +0000 en-US hourly 1 http://wordpress.org/?v=3.8.2 Technical Debt Red October http://www.ontechnicaldebt.com/blog/technical-debt-red-october/ http://www.ontechnicaldebt.com/blog/technical-debt-red-october/#comments Tue, 08 Apr 2014 13:40:09 +0000 http://www.ontechnicaldebt.com/?p=2981 read more]]> This is a great post by Zvi Band, the Founder of Contactually who describes the trials and tribulations of Technical Debt in an early stage product. He mentions the 4 types of issues that have deeply impacted his users:

  • Modifications affecting overall performance (decline).
  • Frequent Bugs
  • Many usability issues
  • Expanded design having a negative impact on form and function.

As software develops at rapid rates there is pressure for startups to test the product in front of customers but the overwhelming amount of code-level shortcuts taken only increases the technical debt. Even though technical debt at times can be a necessity for early stage products, he acknowledged that fixing the problems should be based on the “USER”. By prioritizing what matters to the user; he was able to manage his debt by tracking product performance, identifying customers burning issues, reviewing Net Promoter Scores, discovering the main concerns from existing customers and new customers. Technical debt is unavoidable to some extent but acknowledging that it is a problem is the first step in managing those issues. So don’t burden your users with your Debt, strive to be technical debt free.

Find out more in the full post here: http://zviband.com/posts/technical-debt-red-october/

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-red-october/feed/ 0
Technical Debt Study http://www.ontechnicaldebt.com/blog/technical-debt-study/ http://www.ontechnicaldebt.com/blog/technical-debt-study/#comments Mon, 03 Mar 2014 19:05:25 +0000 http://www.ontechnicaldebt.com/?p=2949 read more]]> Research on Technical Debt helps us understand how to manage it better! If you deal with technical debt on a daily basis, spend 15 minutes filling in this quick survey : http://bit.ly/1a0wt16

Dear Participant,

In an effort to understand software practitioner perceptions of technical debt, we are requesting your participation in our research study.

The goals of this study are as follows:

1.  Gather insights from practitioners with varying years of experience and roles in the software development industry on technical debt

2.  Extract commonalities and differences in their perceptions

3.  Establish a foundation for further research in technical debt

The potential benefits of this study include:

1.  Establish definition(s) for technical debt for further clarification of the metaphor for practitioners and researchers

2.  Report industrial practices for quantifying, communicating, and incurring technical debt

These benefits will enhance researcher and practitioner understanding of the technical debt metaphor.

You are being asked to participate in a short survey on Technical Debt. Your responses are confidential. We will not keep record of any personally identifiable information, and all data will be analyzed as a group.

We estimate that it will take you approximately 15 minutes to complete the survey. Simply click on the link below or cut and paste the URL into your browser to access the survey: http://bit.ly/1a0wt16

We would appreciate your response by March 31, 2014 Midnight CST. Your input is very important to us and will be kept strictly confidential (used only for the purposes of research for this project). This research has been approved by the Mississippi State University Institutional Review Board (IRB HRPP Study #13-200).

 

Zadia Codabux

PhD Graduate Student

Department of Computer Science and Engineering

Mississippi State University

Butler Hall Rm 215

662-325-2756 (Main Office)

zc130@msstate.edu

 

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-study/feed/ 0
Cost of Delay Due to Technical Debt http://www.ontechnicaldebt.com/blog/cost-of-delay-due-to-technical-debt/ http://www.ontechnicaldebt.com/blog/cost-of-delay-due-to-technical-debt/#comments Fri, 14 Feb 2014 21:12:48 +0000 http://www.ontechnicaldebt.com/?p=2942 read more]]> Interesting post from Johanna Rothman about the cost of delay that technical debt can cause. She mentions three types of technical debt:

  • Insufficiently automated build systems
  • Insufficient automated tests
  • System-level software flaws

While we’re more accustomed to looking at the software flaws as the primary driver of technical debt, Johanna focused this post on a story about a large engineering organization that used to take three full weeks to build a version of their product. Of course their release schedule is once every 18 months. If they want to speed that up, the pain of building the system had to be reduced through automation. Interesting to consider whether this is really technical debt, or just a lack of technical infrastructure. We’ll let you decide.

Read the full post here: http://www.jrothman.com/blog/mpd/2014/02/cost-of-delay-due-to-technical-debt-part-4.html

Also check out our expert interview with Johanna Rothman where she discusses pragmatic ideas on how to manage IT debt.

]]>
http://www.ontechnicaldebt.com/blog/cost-of-delay-due-to-technical-debt/feed/ 0
Technical Debt http://www.ontechnicaldebt.com/blog/technical-debt/ http://www.ontechnicaldebt.com/blog/technical-debt/#comments Wed, 04 Dec 2013 15:06:05 +0000 http://www.ontechnicaldebt.com/?p=2935 read more]]> This blog post just came to our attention, because of the issues experienced on Dec 2 at RBS and Natwest in the UK. This post cites a BBC article that predicted something like this happening back in January. It seems the accumulation of Technical Debt has reared its ugly head again in yet another major consumer bank. For RBS, unfortunately, it’s not the first time though. Someone at that institution needs to look at the twitter capture in this post and start minding the structural quality of their banking software.

Read the full blog post here: http://blog.trustiv.co.uk/2013/04/technical-debt

]]>
http://www.ontechnicaldebt.com/blog/technical-debt/feed/ 1
The Debt Collectors http://www.ontechnicaldebt.com/blog/the-debt-collectors/ http://www.ontechnicaldebt.com/blog/the-debt-collectors/#comments Wed, 13 Nov 2013 15:14:00 +0000 http://www.ontechnicaldebt.com/?p=2922 read more]]> This is an entertaining parable about Technical Debt from a Gartner analyst who knows how much of it lurks in the halls of IT. Read the full article here: http://blogs.gartner.com/david_norton/2013/10/25/the-debt-collectors/

]]>
http://www.ontechnicaldebt.com/blog/the-debt-collectors/feed/ 0
5th International Workshop on Managing Technical Debt http://www.ontechnicaldebt.com/blog/5th-international-workshop-on-managing-technical-debt/ http://www.ontechnicaldebt.com/blog/5th-international-workshop-on-managing-technical-debt/#comments Wed, 13 Nov 2013 10:17:45 +0000 http://www.ontechnicaldebt.com/?p=2868 read more]]> Update: Take a look at the presentations from some of the speakers in the industry, including Lockheed Martin, Siemens Healthcare, and IBM on how they manage and calculate Technical Debt.

SEI is organizing a new workshop on managing Technical Debt, taking place in Baltimore, 9 October 2013. This workshop will re-group industry folk who deal with Technical Debt on a day-to-day basis (Siemens, Cisco, Boeing, Northrop, IBM) with academics and industry thought leaders such as Dr. Bill Curtis from CAST, Israel Gat from Cutter Consortium, and Martin Fowler and Jim Highsmith from ThoughtWorks.

The goal of this session is to create a combination of experience reports in order to be better understand the Technical Debt phenomenon, and

  • Define and validate Technical Debt metrics
  • Create strategies to mitigate and repay Technical Debt
  • Discuss tactics inside organizations to address Technical Debt outside of the technical realm

Official website: http://www.sei.cmu.edu/community/td2013esem/

Venue: http://umbc.edu/eseiw2013/location.shtml

Regsitration here: http://www.regonline.com/Register/Checkin.aspx?EventId=1233355

]]>
http://www.ontechnicaldebt.com/blog/5th-international-workshop-on-managing-technical-debt/feed/ 0
Technical Debt: Do Not Under-Estimate the Danger http://www.ontechnicaldebt.com/blog/technical-debt-do-not-underestimate-the-danger/ http://www.ontechnicaldebt.com/blog/technical-debt-do-not-underestimate-the-danger/#comments Thu, 19 Sep 2013 19:08:43 +0000 http://www.ontechnicaldebt.com/?p=2912 read more]]> We all know that going into financial debt can be risky when not managed correctly. And although the metaphor Technical Debt may seem like a more ambiguous topic, the same terms apply.

Check out this great presentation from Lemi Orhan, Principal Engineer at Sony, who describes the pains and costs associated with taking on Technical Debt:

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-do-not-underestimate-the-danger/feed/ 0
Technical Debt and Vendor Lock-In http://www.ontechnicaldebt.com/blog/technical-debt-and-vendor-lock-in/ http://www.ontechnicaldebt.com/blog/technical-debt-and-vendor-lock-in/#comments Tue, 10 Sep 2013 22:02:01 +0000 http://www.ontechnicaldebt.com/?p=2907 read more]]> How do we know we are locked in with a vendor? The most important key to this question is “data”… which is what everybody should be worried about. A recent blog post on Business 2 Community describes the situation of vendor lock-in as not being able to get your data out of your tool or custom-built application into another. Just like a body at rest, data has inertia, and moving it requires different amount of efforts. Some systems however, require much more effort to exit.

Putting this into context in the application development world, data is only a component of our overall application landscape. Before re-platforming or re-developing  an application, it’s therefore essential to look past the keystone and see the rest of the arch. We are building the legacy applications of tomorrow, today. So thinking about sunset planning and replacements now can make technical debt a manageable expense in your future. Look at all sources of potential debt early and avoid a big balloon payment at the end of service!

You can read the full blog post on Technical Debt and vendor lock-in here: http://www.business2community.com/tech-gadgets/technical-debt-vendor-lock-0607995

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-and-vendor-lock-in/feed/ 0
Technical Debt in the Era of Transient Competitive Advantage http://www.ontechnicaldebt.com/blog/technical-debt-in-the-era-of-transient-competitive-advantage/ http://www.ontechnicaldebt.com/blog/technical-debt-in-the-era-of-transient-competitive-advantage/#comments Wed, 04 Sep 2013 12:42:48 +0000 http://www.ontechnicaldebt.com/?p=2896 read more]]> A situation that I and various consultants in the Cutter Agile Practice are often exposed to is a pressing need to reduce technical debt. A prospect calls with respect to some software assets that have ceased to perform adequately. What we almost invariably find once we do the Technical Debt Assessment is that over time the client’s codebase got both bloated and spaghetti-like. As a result, the client is struggling with 10M, 20M or 50M lines of tangled code. The combination of size with “spaghetti tangles” renders it hard to effectively adapt the software as in such code even changing/adding a single line of code could require significant integration and regression efforts. The situation is essentially similar to Clausewitz’s quip about war: “Everything in war is simple, but the simplest thing is difficult”.

SpaghettiCode_II

Figure 1: Your code, Sir!

If you find yourself these days in a high technical debt situation, you are facing two major challenges:
A) the classic challenge of technical debt; and,
B) the challenge of technical debt in the era of transient competitive advantage.

To read the full article, visit the Cutter Consortium blog here.

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-in-the-era-of-transient-competitive-advantage/feed/ 0
Are We There Yet? Thoughts on Technical Debt Research and Practice http://www.ontechnicaldebt.com/blog/are-we-there-yet-thoughts-on-technical-debt-research-and-practice/ http://www.ontechnicaldebt.com/blog/are-we-there-yet-thoughts-on-technical-debt-research-and-practice/#comments Fri, 26 Jul 2013 19:37:16 +0000 http://www.ontechnicaldebt.com/?p=2883 read more]]> The strategic management of technical debt has gained visibility with the increase in popularity of agile methods. Consequently, it is of extreme importance to focus research on understanding, quantifying and properly managing technical debt. In the software engineering research community, there is a lack of consensus among stakeholders regarding what technical debt really is. There are also many open research questions regarding technical debt.  Examples of diverging opinions include but are not restricted to:

  • What is the definition of technical debt?
  • What is quality debt vs. technical debt?
  • Is technical debt an appropriate metaphor (to financial debt), i.e. can these financial concepts be applied to software development?

Practitioners seem divided in defining technical debt [1], and their perspectives can conflict with academics. Historically, academics rely on the practitioners to validate their theories and test their hypotheses. These diverging opinions of the research community have evolved since the 1992 OOPSLA report definition of Technical Debt by Ward Cunningham [2]:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”

This definition is the most widely accepted idea of technical debt. However, technical debt is no longer restricted to code. The concept has been extended to include other artifacts in the software development life-cycle. Technical debt is no longer just the “internal things” (such as the code) as originally stated by Cunningham, but the concept has been extended to include “external things” such as design debt, testing debt, documentation debt, and defect debt [3].

I recently attended the Fourth International Workshop on Managing Technical Debt (MTD) where practitioners and academics came together to discuss the state-of-the-art in technical debt research. At the MTD workshop, Steve McConnell provided insight on the evolution of technical debt since its conception by suggesting:

“[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 (including increased cost over time).”

In addition, MTD provided an opportunity for participants to discuss open technical debt research questions. For example, one topic discussed was “What is quality debt?” Many participants agreed that “quality debt” is different from technical debt and that defects should not be considered as technical debt but as “quality debt.”  Based on this reasoning, defect debts (which are known defects that are not yet fixed) would no longer be part of technical debt.

However, my stance is different… Based on McConnell’s reasoning above, I consider known defects to be part of what constitute technical debt because a decision to defer a defect is made consciously. When a decision to not resolve a defect is made, you know this is something that you haven’t fixed yet. Resolving the defect will cost you at some point in the future to fix, possibly more later (principal + interest) than it would to fix now (principal only). Defects have the potential to compromise the quality of software and you will have to come back and fix it eventually.

Next, let’s have a look at the terminologies related to technical debt. “Software debt” and “quality debt” are terms that are often used as substitutes or to relate to technical debt. Sterling [4] states that software debt consists of technical debt, quality debt, and design debt, etc., thereby clearly stating that technical debt and quality debt are different. He defines “technical debt” as “activities that a team or team members choose not to do well now and will impede future development if left undone” and describes “quality debt” as the “diminishing ability to verify the functional and technical quality of software”.

Based on these 2 different notions of quality debt, which definition do you think relates more closely to technical debt?

Another term used for technical debt is “IT debt” by Gartner [5]. Gartner defines “IT debt” as the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state. Is technical debt cost really only the cost of clearing the backlog? Technical debt measurement is commonly expressed in terms of principal – cost of eliminating the debt (e.g. through refactoring) and interest – increased costs of to eliminate the debt at a later date [6]. However, there is more complexity involved in calculating this principal and interest costs. When releasing software, the company also incurs some liabilities e.g. handling service desk calls for potential issues that can arise, performing changes to the code (patch release, software updates, etc.), and handling deployment issues among others. These liabilities cost money to service them and most importantly, have risks associated with them. It is so difficult to predict with certainty the consequences of incurring technical debt. Therefore, the cost to handle technical debt goes beyond the costs in person-hours to handle the debt. This view of technical debt is often overlooked by the software engineering community when attempting to quantify technical debt.

Following that argument, can we still say technical debt is a metaphor (to financial debt)? Can we quantify technical debt as precisely as we can quantify financial debt? Can we predict the risks associated with incurring technical debt?

Ultimately, despite attempts to fill the gaps in understanding of technical debt through initiatives like the MTD workshop and blog posts, the technical debt concept is still at a primitive stage of research. The deeper you explore the open issues, the more questions pop up in your mind. The bottom line is – technical debt is a fascinating concept with plenty of research opportunities but before further evaluating these open issues, should we (practitioners and academics) not all agree on the basics i.e., “How do we define technical debt and what constitutes technical debt?” There is still some more work that we, as a community, need to do to get there!

As part of my research initiative to study some of the above-mentioned opened issues on technical debt, I will be conducting a survey with industry practitioners. If you would like to participate in the survey to share some of your insights, please send an email to zc130@msstate.edu.

References
[1]           Z. Codabux and B. J. Williams, “Managing Technical Debt: An industrial case study”, Proceedings of the 4th International Workshop on Managing Technical Debt, 2013 [to appear].
[2]           W. Cunningham, “The WyCash portfolio management system,” in Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum), Vancouver, British Columbia, Canada, 1992, pp. 29–30.
[3]           C. Seaman and N. Zazworka, “IEEE/Lockheed Martin Webinar on Identifying and Managing Technical Debt,” Nov-2011. [Online]. Available: http://www.nicozazworka.com/research/technical-debt/.
[4]           C. Sterling, Managing Software Debt: Building for Inevitable Change, 1st ed. Addison-Wesley Professional. Part of the Agile Software Development Series series., 2010.
[5]           “Gartner Estimates Global ‘IT Debt’ to Be $500 Billion This Year, with Potential to Grow to $1 Trillion by 2015,” Sep-2010. [Online]. Available: http://www.gartner.com/newsroom/id/1439513.
[6]           N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya, R. Sangwan, C. Seaman, K. Sullivan, and N. Zazworka, “Managing technical debt in software-reliant systems,” in Proceedings of the FSE/SDP workshop on Future of software engineering research, New York, NY, USA, 2010, pp. 47–52.

]]>
http://www.ontechnicaldebt.com/blog/are-we-there-yet-thoughts-on-technical-debt-research-and-practice/feed/ 0