On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 30 Oct 2014 09:00:52 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.2 Technical Debt Takes Many Forms http://www.ontechnicaldebt.com/blog/technical-debt-takes-many-forms/ http://www.ontechnicaldebt.com/blog/technical-debt-takes-many-forms/#comments Thu, 30 Oct 2014 09:00:52 +0000 http://www.ontechnicaldebt.com/?p=3177 read more]]> Most know the term technical debt in the way that it slows down development and can cause architectural problems, however, this post does well in pointing out other manifestations of the term that also need to be considered under the umbrella of tech debt.

Dead Code, for example, should be considered a form of debt. When there is a live function that is only used from dead code it is hiding the fact that that function is dead as well – meaning that dead code needs to be worked through and categorized as dead before any new work can be done. Therefore, like any other way of addressing tech debt, dead code must be found and discarded. Unused repositories or branches also need to be deleted or put in to cold storage – because every time someone starts working they will need to spend time wondering what is dead or alive taking up time with unnecessary work. Furthermore, although it can be useful to use the backlog to ticket items that need work, a backlog that is too large and flooded is also a form of technical debt. They can be difficult to manoeuvre in order to prioritize items. Therefore, only 3 months worth of work should be put in the backlog, where as longer term items should be on a roadmap. Another often useful tool, documentation, when out of date can be harmful and a source of debt. Proper documentation should be a team member’s responsibility or be added to the definition of ‘done’ in order to reduce the debt accumulated by such unused documentation.

This post recognizes each of these things as debt, and therefore make it simpler to know what to do in order to reduce technical debt. To read the full post go to: http://www.robg3d.com/2014/10/technical-debt-takes-many-forms/

http://www.ontechnicaldebt.com/blog/technical-debt-takes-many-forms/feed/ 0
Technical Debt – Out of the Red and Into the Black http://www.ontechnicaldebt.com/blog/technical-debt-out-of-the-red-and-into-the-black/ http://www.ontechnicaldebt.com/blog/technical-debt-out-of-the-red-and-into-the-black/#comments Wed, 29 Oct 2014 09:00:29 +0000 http://www.ontechnicaldebt.com/?p=3173 read more]]> CIOs often feel that the rest of their business doesn’t understand the constraints that they are working with, as they are asked to do more when only one fifth of their IT budgets are available for transformation. Here the concept of technical debt can be harnessed by the CIO to highlight issues facing them and their teams to management and other non-technical parts of their business.

This post promotes application rationalism as a logical solution to the age old problem of budget constraints and breaking even. What this means is that the life of applications (often applications that are burdened by technical debt) can be extended through rationalization and modernization; consolidating similar applications, replacing or eliminating out dated applications, modernizing platforms and languages to more up to date option in order to reduce operational risks. These steps all are modes of reducing by 20-30% total cost of ownership of certain applications, which in turn helps reduce technical debt.

Rationalization techniques thus become important for any CIO in order to build up long term savings and produce a debt free application portfolio that fully supports business growth.

To read the full post go to: http://www.csc.com/application_modernization/blog/111697/114569-technical_debt_out_of_the_red_and_into_the_black?adbid=524926623418548224&adbpl=tw&adbpr=599689553& 

http://www.ontechnicaldebt.com/blog/technical-debt-out-of-the-red-and-into-the-black/feed/ 0
Measuring and Managing Technical Debt – A CISQ Presentation http://www.ontechnicaldebt.com/blog/measuring-and-managing-technical-debt-a-cisq-presentation/ http://www.ontechnicaldebt.com/blog/measuring-and-managing-technical-debt-a-cisq-presentation/#comments Thu, 23 Oct 2014 09:00:24 +0000 http://www.ontechnicaldebt.com/?p=3167 read more]]>

CISQ is the Consortium for IT Software Quality, a special interest group of the Object Management Group organized to create standards for measuring software quality, including the definition of technical debt and factors that influence it: security, performance, reliability, and maintainability. 

A few months ago the Consortium for IT Software Quality (CISQ) had a presentation on Measuring and Managing Technical Debt by Dr. Bill Curtis SVP & Chief Scientist for CAST Research Labs and Director of CISQ. This presentation is a great tool for those who want a more technical and deep look into technical debt and how it translates to business uses. In the presentation the definition of technical debt is presented as:

“The future cost of defects remaining in code at release, a component of the cost of ownership”

The uses of the technical debt metaphor presented above are established when an estimate of technical debt (in other words the tech debt principal: the cost of fixing problems remaining in code after release that must be remediated) are as follows:

  • Calculating cost of ownership
  • Assessing business risk
  • Explaining IT cost of quality
  • Managing Portfolio Quality

In order to enact the uses of technical debt, the principal of technical debt must be estimated. Dr. Curtis in his presentation shows the inputs for estimating technical debt (or in other words the indicators that help estimate the cost of fixing technical debt). These indicators include:

  • Test results and static analysis – which come from application quality problems
  • Historical data maintenance – measured from hours taken to correct problems
  • IT supplier finance records – based off of developer’s burdened hourly rate

The cumulation of these inputs will then give you your technical debt principal. An example of how important it is to be aware of technical debt cost is that a conservative estimate of this cost in most business applications  is $3.61 per LOC. Estimates of technical debt can be a significant tool to management in understanding and managing IT costs and risks as 70% of technical debt cost is in IT costs and 30% in business risk.

In order to translate technical debt into a business mindset productivity has to be understood as a “declining function that compares the amount of  product produced to the effort required to produce it, unless action is taken”.

However, one of the pitfalls that often occurs regarding technical debt is translating the technical language surrounding the term into business measures. So here, the presentation delves into how certain technical measurement have their business equivalents.

  • Robustness = availability (this usually has to do with operational outages and slow recovery)
  • Performance = work efficiency (the signal of this being degraded response of the product)
  • Security = data protection (breaches and theft)
  • Transferability = IT productivity (lengthy comprehension of the product and it’s problems)
  •  Changeability = delivery speed (excessive effort put into the products maintenance)

In addition to these more abstract bits of information in explaining technical debt to management, and of how to estimate technical debt principal – there are several studies that are used in the presentation to demonstrate the effectiveness of reducing technical debt in relation to cost of maintenance and how higher technical debt, even by just a fraction, can severely hamper productivity.

To see the whole presentation and more presentations from CISQ on technical debt go to http://it-cisq.org/ and request a free membership (becoming a free member keeps you up-to-date with standards work and puts you on the invite list for events, as well as giving you access to seminars and presentations online).

http://www.ontechnicaldebt.com/blog/measuring-and-managing-technical-debt-a-cisq-presentation/feed/ 0
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