On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 16 Oct 2014 09:06:48 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.2 Faster Software Development with (Smart) Technical Debt http://www.ontechnicaldebt.com/blog/faster-software-development-with-smart-technical-debt/ http://www.ontechnicaldebt.com/blog/faster-software-development-with-smart-technical-debt/#comments Thu, 16 Oct 2014 09:06:48 +0000 http://www.ontechnicaldebt.com/?p=3162 read more]]> Technical debt often arouses bad associations in developers’ minds because so often when the term is brought up, it is almost always a bad thing. Here is a post that presents an argument for using technical debt as a business tool and the steps that must be taken to use it as thus. Much of technical debt is used out of “sheer desperation” but the technical debt that this post promotes is only validated if it has been assured that it can be afforded to pay back the debt taken on and if taking on the debt gives something that will appreciate in value. Technical debt shouldn’t be the basis of any project, but a tool for making one that will ultimately be beneficial.

The steps to incurring technical debt as a prudent business practice that are mentioned in this post are:

  1. Get the consensus of the team to take on technical debt for a certain project – it is a serious decision that should not be taken alone, but with input from the team.
  2. Once the decision to incur technical debt has been taken, steps must be taken to contain the debt, making sure that the ‘hacks’ used are modular and can be reunited gracefully into the system around it once fixed.
  3. Putting relevant and helpful comments on the code is necessary so that later it can be worked on.
  4. Once the code has been completed it should be looked over with scrutiny to make sure it lives up to the responsibilities it must fulfill.
  5. Finally, having a plan to pay back the debt – whether this be when it takes 30% more time to modify than it should or when it generates more than 5 bugs per quarter.

This post puts forward the idea of using technical debt as an act of pragmatism that when practiced with care and purpose can be a valuable skill.

To read the full post go to: http://revelry.co/2014/10/09/faster-software-development-with-smart-technical-debt/

]]>
http://www.ontechnicaldebt.com/blog/faster-software-development-with-smart-technical-debt/feed/ 0
Managing Technical Debt with Agile: Care About Your Code http://www.ontechnicaldebt.com/uncategorized/managing-technical-debt-with-agile-care-about-your-code/ http://www.ontechnicaldebt.com/uncategorized/managing-technical-debt-with-agile-care-about-your-code/#comments Tue, 14 Oct 2014 09:00:09 +0000 http://www.ontechnicaldebt.com/?p=3136 read more]]> Managing technical debt is easiest when there is an outline to help your development team discuss how classify and prevent technical debt. This post does just that. Technical debt is classified in several ways according to Martin Fowler’s tech debt quadrant (prudent and deliberate debt; reckless and deliberate debt; reckless and inadvertent debt; prudent and inadvertent debt) each with their justifications and causes.

This image, and the in depth explanation of each type of debt in this post could be used for any organization to decide what tech debt is acceptable and which is not. Another point made in this post is that one of the greatest problems that affect legacy projects is a high amount of technical debt which can slow down productivity – resolving this means setting aside after every iteration to service technical debt . This is just a general technique to managing technical debt that the article mentions. It also comments on a cultural shift that may need to take place within teams where technical debt is no longer allowed except if it can be justified business strategy.

The post goes on to list possible techniques to preventing technical debt:

  1. Draw the line – this refers to the cultural shift in no longer allowing tech debt
  2. Having a strong definition of done – adhering to code standards
  3. Test driven development – write a test, if the code fails, rework it
  4. Engaging in collaborative design – in order to avoid subject matter experts

It also lists how to manage technical debt using agile:

  1. Using a debt backlog – only when tech debt is business justified
  2. “Service the Debt” – commit to making up for technical debt
  3. Makeup stories – Make colour-coded placeholders indicating non-user story work
  4. Have dedicated sprints to service the debt accumulated

This post is a streamlined ‘handbook’ on how to manage technical debt in agile. It points out several modes of managing and preventing technical debt which are worth learning more about. To read the full post go to: http://www.agilerecord.com/managing-technical-debt-agile/

 

 

]]>
http://www.ontechnicaldebt.com/uncategorized/managing-technical-debt-with-agile-care-about-your-code/feed/ 0
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