On Technical Debt http://www.ontechnicaldebt.com Online Community Fri, 26 Sep 2014 21:39:19 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.2 Technical Debt: Avoiding Loan Default http://www.ontechnicaldebt.com/uncategorized/technical-debt-avoiding-loan-default/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-avoiding-loan-default/#comments Fri, 26 Sep 2014 21:39:19 +0000 http://www.ontechnicaldebt.com/?p=3131 read more]]> Here is a straightforward post on the contributing factors of technical debt. A list of ways in which technical debt usually accumulates includes: business pressures (when meeting deadlines becomes more important than completing remaining tasks), not constructing code flexibly, lack of unit testing, and lack of shared knowledge between team members. From here it can be understood that technical debt impedes productivity by not being able to add onto code efficiently and increasing time for maintenance. If this debt is left to build up it becomes unmanageable and the interest on that debt will increase until the due date arrives. The due date for technical debt is when payments are not being made on debts but there aren’t any more charges being added onto the balance. If this however changes and more charges are added because there is less time than tasks to complete –  the loan goes into default. Once the loan is in default, questions and frustrations from users and developers begin to pile up – which creates an extra impediment to a productive work place. Thus it becomes necessary from the start, to avoid accumulating massive amounts of technical debt; whether this be through automation, proper unit testing or documentation.

To read the full post go to: http://sldn.softlayer.com/blog/jbrown/Technical-Debt#utm_source=twitter&utm_medium=social&utm_content=are-you-drowning-in-debt-tecnical-debt-that-is-learn-how-to-keep-the-creditors-from-knocking-on-your-door&utm_campaign=developer_blog

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-avoiding-loan-default/feed/ 0
Paying Down Technical Debt: Work Smarter Not Harder http://www.ontechnicaldebt.com/blog/paying-down-technical-debt-work-smarter-not-harder/ http://www.ontechnicaldebt.com/blog/paying-down-technical-debt-work-smarter-not-harder/#comments Wed, 24 Sep 2014 09:00:30 +0000 http://www.ontechnicaldebt.com/?p=3126 read more]]> This post starts off with an illuminating comparison: between IT shops that work strenuously trying to complete 2 weeks worth of work in 6 days and achieve very little, and other organizations that seem to make much more progress in their work with less hours. The idea of working smarter – not harder – comes into play here and this can often mean having less technical debt.

“It’s when you have urgency that takes precedence over the right thing to do. In that rush, you’re not making decisions the right way, you’re just getting things done really quickly in the heat of the moment. And you have to go back and fix those later…”

This is usually the tradeoff that incurs technical debt – quality vs. deadlines. In order to help reduce the technical debt that many organizations take on because of this tradeoff enterprises should consider running what this post calls “blameless post-mortems”. These post-mortems require an acknowledgement of the debt present and time set aside to fix the problems present without blame. To avoid technical debt build up in the long run continuous testing of operations and applications is necessary. However, a problem that many organizations have is not a lack of testing, but undoubted faith in the testing they have at present, when in fact it is insufficient. In order to avoid this trap performance testing is a possible solution to catch applications that have been made under best practices but don’t run properly. The post ends stating that continuous improvement is not for the impatient, but is an investment for long term productivity.

To read the full post go to: http://devops.com/features/paying-technical-debt/

]]>
http://www.ontechnicaldebt.com/blog/paying-down-technical-debt-work-smarter-not-harder/feed/ 0
Using Agile Techniques to Pay Back Technical Debt http://www.ontechnicaldebt.com/blog/using-agile-techniques-to-pay-back-technical-debt/ http://www.ontechnicaldebt.com/blog/using-agile-techniques-to-pay-back-technical-debt/#comments Fri, 19 Sep 2014 09:00:31 +0000 http://www.ontechnicaldebt.com/?p=3122 read more]]> Acknowledging that some form of technical debt exists in every codebase is paramount to managing debt and staying in “the black”. Asides from the fact that technical debt kills productivity thus leading to economic downsides, there exists a psychological downside to technical debt. If a developer dreads dealing with code that is brittle and filled regression bugs this could lead to high developer turnover within an organization.

This is a great post that provides helpful tools to deal with the issue of mounting technical debt. In the cost of change curve – two curves are displayed: rapid-but-untested coding and simple, test-driven coding. The later has higher starting cost but remains steady over time, while rapid untested coding has a lower starting cost, but future costs of ownership skyrocket and become more expensive. It becomes clear that “quality software takes the least amount of time to develop. If you have code that is simple as possible, tests that are complete and a design that fits just right, additions and changes happen in the fastest possible way because the impact is lowest. Consequently, if you hack something out, the more you hack the slower you go because the cost of addition or change grows with each line of code.” Therefore longterm thinking leads to higher productivity and lower costs in an organization; the mindset should be about the products lifespan not a project to project mindset.

This post describes the thinking that needs to be used within an organization to avoid high build-up of crippling technical debt. A sample work flow for how to deal with technical debt is laid out. Some of the steps mentioned are: recognition of debt, quantifying where the most debt it, agreeing on what debt to pay off first, and fixing the debt. This seems self explanatory but it is based on a concept that provides an interesting way to explain to non-technical stakeholders the necessity of paying back tech debt: when the demand for development exceeds what the team can fulfill a bottleneck is created. In other words, when there is too much technical debt, the work to fix the code and be able to add onto it becomes more difficult and thus slows down development (the bottleneck-effect). This understanding that productivity lulls because of technical debt is necessary to be able to sell a plan to resolve it. Being able to convince non-technical supervisors that the technical debt accumulated is not due to a poor job – but the best job possible under the requested deadline is helpful to getting a plan in action to solve the issue.

To read the full post and see the example workflow listed and some helpful tips to “selling” the payment of technical debt go to: http://msdn.microsoft.com/en-us/magazine/ee819135.aspx

]]>
http://www.ontechnicaldebt.com/blog/using-agile-techniques-to-pay-back-technical-debt/feed/ 0
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