On Technical Debt http://www.ontechnicaldebt.com Online Community Mon, 15 Sep 2014 23:53:05 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.2 Productive vs. Unproductive Work: Measuring Technical Debt http://www.ontechnicaldebt.com/blog/productive-vs-unproductive-work-measuring-technical-debt/ http://www.ontechnicaldebt.com/blog/productive-vs-unproductive-work-measuring-technical-debt/#comments Mon, 15 Sep 2014 08:55:25 +0000 http://www.ontechnicaldebt.com/?p=3119 read more]]> Definitions of technical debt often revolve around additions made to code ‘sloppily’ (or in the case of this post ‘hackily’) which mount up to difficulty in adding features to the codebase. This post points out that in order to measure the level of the technical debt that has been accumulated  because of  ‘hack’ changes made, the company needs to look at the proportion of work time spent productively vs. the amount of work time spent dancing around these hacks in the codebase. This post gives a list of examples that are unproductive uses of work time due to technical debt ( i.e. finding, reading and understanding informal documentation or spending time in meetings trying to convince engineers that changing old code is a good idea).

The best snippet of this post comes at the end of it – when a company reaches 90% technical debt where only six minutes out of every hour of work time are spent productively they are in a terminal state. This danger isn’t only for large companies with old codebases but can also present itself in newer agile companies which are based on incrementalism. In order to avoid being paralyzed by technical debt than an awareness of it as a danger and time set aside to address it are needed.

To read the full post go to: http://nanodome.wordpress.com/2014/09/07/what-is-technical-debt/

http://www.ontechnicaldebt.com/blog/productive-vs-unproductive-work-measuring-technical-debt/feed/ 0
Managing Technical Debt – Part 1 http://www.ontechnicaldebt.com/blog/managing-technical-debt-part-1/ http://www.ontechnicaldebt.com/blog/managing-technical-debt-part-1/#comments Wed, 10 Sep 2014 09:03:48 +0000 http://www.ontechnicaldebt.com/?p=3115 read more]]> This is a post that gives a good overview of how to manage technical debt by knowing that in order to keep tech debt in check you have to balance time to market and quality. The best run businesses take on technical debt but also set up time to pay it back so that their levels of debt fluctuate in a sawtooth pattern. Poorly run businesses keep taking on debt never paying back until their revenues are consumed by interests from their tech debt. One of the interesting parts of this post is that it makes clear that technical debt is not only a technology company’s problem, but is a problem for any business. This is a good comment to put out there as an issue that often arrises in managing technical debt is the difficulty to communicate the importance of the debts payment to non-technical managers.

To read the full post go to: http://blog.syspro.com/2014/09/02/managing-technical-debt-1

http://www.ontechnicaldebt.com/blog/managing-technical-debt-part-1/feed/ 0
When Code is Considered Technical Debt http://www.ontechnicaldebt.com/uncategorized/when-code-is-considered-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/when-code-is-considered-technical-debt/#comments Mon, 08 Sep 2014 09:00:28 +0000 http://www.ontechnicaldebt.com/?p=3113 read more]]> This post tries to explain when code should be considered technical debt, rather than define the term by itself. For example, the post explains that technical debt is often described as code that is difficult to maintain or does not fall under the idea of ‘good code’. The belief that there is technical debt in code can come from a lack of familiarity with the code being worked on. If the person coding is not familiar with the code base, they will most likely be less productive and can attribute that drop in productivity to technical debt – or if the code does not use the best practices that the person coding is used to they are less likely to feel familiar with the code and will think there is technical debt. This post comes to the conclusion then that the highest interest is paid on technical debt when the code is new to the person working on it. Thus there needs to be a decision made about how often people who are unfamiliar with the code will be working on it, to be able to make the easiest to understand code as possible.

To read the full post makes and see the relation of code familiarity and technical debt go to: http://trueclarity.wordpress.com/2014/09/04/when-code-is-considered-technical-debt/

http://www.ontechnicaldebt.com/uncategorized/when-code-is-considered-technical-debt/feed/ 0
The Law of Brittleness… or Technical Debt? http://www.ontechnicaldebt.com/blog/the-law-of-brittleness-or-technical-debt/ http://www.ontechnicaldebt.com/blog/the-law-of-brittleness-or-technical-debt/#comments Sat, 06 Sep 2014 09:00:57 +0000 http://www.ontechnicaldebt.com/?p=3109 read more]]> There have been many posts that point out problems with the metaphor of technical debt, like the recent post Technical Debt 101: More Speed, Less Haste where the metaphor is dissected. “The Law of Brittleness” does more than explain technical debt but goes as far as to change it’s name.  The term technical debt was an attempt to, using business-friendly terms, explain the intangible aspect of code – the ability to change it. This post points out that the problem with the term technical debt is that it does not convey the proportional implications of changing software. The more changes that are made, the more brittle the software becomes. Businesses need to be able to react to changing demands, so having brittle software that is difficult and costly to alter is not in their interests. Brittleness is just another word for technical debt, but could be useful when explaining the investments that need to be made to prevent it or pay it off.

To read the full post and see how brittleness compares to technical debt go to: http://www.scrambledbrains.net/2014/02/14/the-law-of-brittleness/

http://www.ontechnicaldebt.com/blog/the-law-of-brittleness-or-technical-debt/feed/ 0
Technical Debt, Technical Liability, and Moral Hazard http://www.ontechnicaldebt.com/blog/technical-debt-technical-liability-and-moral-hazard/ http://www.ontechnicaldebt.com/blog/technical-debt-technical-liability-and-moral-hazard/#comments Thu, 04 Sep 2014 09:00:23 +0000 http://www.ontechnicaldebt.com/?p=3107 read more]]> Moral hazard is a situation when a party is more likely to take a risk because they are not the ones bearing the possible costs of that risk. This post concludes that one of the sources that can contribute to technical debt is moral hazard – which comes from the person coding being motivated to get the code done quickly and not being cautious of cutting corners because of their lack of commitment to the possible costs. This connects to another interesting point that this post makes; code deficiencies do not become technical debt until there is a commitment to address the deficiencies. Basically, it’s not a debt if you don’t have to pay it off – but creating these deficiencies raises the probability of having to commit to fix the code. This probability of the costs that might be taken on is what this post calls technical liability. The liability must be understood in order to decide to invest in reducing the deficiencies created by technical debt.

This post is an interesting addition to the differing perspectives surrounding technical debt and has some new insights surrounding culture of creating technical debt. To read the full post go to: http://murraycantor.com/2014/07/30/technical-debt-technical-liability-and-moral-hazard/

http://www.ontechnicaldebt.com/blog/technical-debt-technical-liability-and-moral-hazard/feed/ 0
Technical Debt: Do’s and Don’ts http://www.ontechnicaldebt.com/uncategorized/technical-debt-dos-and-donts/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-dos-and-donts/#comments Tue, 02 Sep 2014 09:18:34 +0000 http://www.ontechnicaldebt.com/?p=3098 read more]]> This is a kind of ‘wiki-how’ on how to manage technical debt in an agile environment – the right way. Not that there is one right way, but there are a few basics that this article points out. Technical debt, like any other debt should be budgeted in the release and iteration planning. Ultimately, the goal of any agile team should be to reduce or eliminate technical debt over time and to treat it as a “low-risk, high-return investment”. Some common pitfalls of managing technical debt are also addressed. For example, pushing technical debt prevention and payment to a minor release and having “hardening sprints” solely for technical debt. Ultimately this is a short post, that is part of larger how to do Agile right article, that points out common problems and solutions to technical debt.

To read the full post go to: https://www.atlassian.com/agile/delivery#!technical-debt


http://www.ontechnicaldebt.com/uncategorized/technical-debt-dos-and-donts/feed/ 0
Confronting Technical Debt http://www.ontechnicaldebt.com/blog/confronting-technical-debt/ http://www.ontechnicaldebt.com/blog/confronting-technical-debt/#comments Thu, 28 Aug 2014 19:10:52 +0000 http://www.ontechnicaldebt.com/?p=3103 read more]]> There are a lot of posts out there that talk about how to handle technical debt so it doesn’t get out of control and start to affect your system’s performance. This post does address the reality of paying off technical debt, but also goes into detail of how to know where to start refactoring for technical debt. The development team, will most likely have a ‘feel’ for what needs to be fixed, but relying on only instinct ignores various other measurements that are useful to paying back technical debt.  What this post says is that to begin to pay back the technical debt that has accumulated the development team must consider not only their instinct, but business needs coupled with objective and subjective  measures. Once the technical debt has been incurred, and a decision has been taken to pay it off – there needs to be some methodology behind the payment.

To read the full post and see some of the details on confronting technical debt go to: http://www.payton-consulting.com/confronting-technical-debt/?utm_source=ReviveOldPost


http://www.ontechnicaldebt.com/blog/confronting-technical-debt/feed/ 0
Technical Debt & Quality – Binary Thinking in an Analog World http://www.ontechnicaldebt.com/uncategorized/technical-debt-quality-binary-thinking-in-an-analog-world/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-quality-binary-thinking-in-an-analog-world/#comments Wed, 27 Aug 2014 15:34:16 +0000 http://www.ontechnicaldebt.com/?p=3088 read more]]> This is really great post that discusses the idea that ‘quality is not negotiable’ and that ‘only technical debt enthusiasts believe that’. The post states that deciding what is negotiable isn’t really the decision of the developer – because they are not paying for the work, and that by ‘negotiating’ quality they are not tech debt enthusiasts but just aware of the trade offs that technical debt offers.

What is most poignant about this post is the example used to present that reality often comes in the way of  perfection: for a team that was working on the code that controlled a space shuttle the last 3 versions of the program of 450,000 lines each had 1 error in each version, and for the last 11 versions of the software there were 17 errors total. A commercial program of comparable complexity would average 5,000 errors. The code for the software shuttle had to be that good, because a minor bug could put the shuttle 3 miles off course. However, even though this code had a $35 million budget and required perfection, it still could only be almost perfect. Realistically perfection in quality is never possible – even in the best of circumstances. This example really highlights how creating code and incurring technical debt or errors, is not just sloppy or lazy work but also inevitable.

To read the full post go to: http://genehughson.wordpress.com/2014/01/26/technical-debt-quality-binary-thinking-in-an-analog-world/

http://www.ontechnicaldebt.com/uncategorized/technical-debt-quality-binary-thinking-in-an-analog-world/feed/ 0
Technical Debt Measurement Webinar: Reversal Strategy Q&A Follow Up http://www.ontechnicaldebt.com/blog/technical-debt-measurement-webinar-reversal-strategy-qa-follow-up/ http://www.ontechnicaldebt.com/blog/technical-debt-measurement-webinar-reversal-strategy-qa-follow-up/#comments Tue, 26 Aug 2014 09:00:21 +0000 http://www.ontechnicaldebt.com/?p=3084 read more]]> Here’s a post from a while back that follows up the Q&A of the webinar we posted on how to reverse your technical debt. The post focuses on how to set up a technical debt measurement program, what tools to use, and how to manage the results you’ve generated from your tech debt measurement program. It also mentions CAST Highlight and CAST Application Intelligence Platform as possible tools for setting up such a program – and red flags that other tools can give superficial results on technical debt, which could misinform about the actual quality of the applications it is reporting on.

To read the full post on how to set up a technical debt measurement program in a large IT setting go here: http://blog.castsoftware.com/technical-debt-measurement-webinar-reversal-strategy-qa-follow-up/

http://www.ontechnicaldebt.com/blog/technical-debt-measurement-webinar-reversal-strategy-qa-follow-up/feed/ 0
Technical Debt – Why not just do the work better? http://www.ontechnicaldebt.com/uncategorized/technical-debt-why-not-just-do-the-work-better/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-why-not-just-do-the-work-better/#comments Mon, 25 Aug 2014 13:01:33 +0000 http://www.ontechnicaldebt.com/?p=3081 read more]]> Here is a post that answers the question: why not just do the work better in order to avoid technical debt? Here it is explained that technical debt is not necessarily consciously done poor work (in the mode of code shortcuts) but also a result of many uncontrollable factors – such as the intrusion of business considerations, aging platforms and changing run-time circumstances. These factors are often not defined as strictly under technical debt but as quality debt, design debt, or architectural debt. However, these all fall under the umbrella of technical debt and affect user satisfaction and can occur, even when nothing is done ‘wrong’. In order to manage your technical debt, this post recommends taking the widest view of technical debt (that which encompasses quality, design and architectural debt) in order to sustain the “evolution of a product over its lifetime”. This provides long-term focus rather than a project to project focus, that can often be the cause of accumulated un-managed technical debt.

To read the full post go to: http://genehughson.wordpress.com/2014/08/16/technical-debt-why-not-just-do-the-work-better/

http://www.ontechnicaldebt.com/uncategorized/technical-debt-why-not-just-do-the-work-better/feed/ 0