On Technical Debt http://www.ontechnicaldebt.com Online Community Fri, 28 Nov 2014 09:00:05 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.3 Technical Debt – What Can You Do http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/ http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/#comments Fri, 28 Nov 2014 09:00:05 +0000 http://www.ontechnicaldebt.com/?p=3221 read more]]> It is often suggested that businesses seek to create minimal viable products. In other words, to only develop the most important core features that allow for the prompt delivery of a product making time to market the most important factor in product development. The inherent problem with this approach is that there has been a conscious decision to only build what is needed right now. Overtime, design can feel cobbled together and difficult to manage.

For example, when writing an application there isn’t a need for user permissions but at some point there will be. At this moment in time adding to the system to manage permissions would be over design, but in the next versions you will need to add users. There are two choices of how to manage adding permissions: 1) take two hours to add a single permission or 2) take 2 days to refactor and make the system more maintainable. The refactoring option significantly reduces the time needed to add permissions in the future. This is technical debt, measuring the difference between a system’s optimal state (refactored solution) and its current state (cobbled together mess of today).

The trouble with technical debt is that business owners have difficulty understanding its consequences because of developers inability to communicate risks in a business-value-driven way. Most businesses ignore it as it takes too much time and costs too much but there are ways to manage technical debt.

To read the full post go to: https://brosteins.com/2014/11/19/technical-debt-can/

http://www.ontechnicaldebt.com/blog/technical-debt-what-can-you-do/feed/ 0
Why is Programming so Hard? – Incidental and Accidental Complexity http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/ http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/#comments Tue, 25 Nov 2014 09:00:24 +0000 http://www.ontechnicaldebt.com/?p=3206 read more]]> Accidental complexity can be referred to as technical debt or sometimes spoken about as incidental complexity – ultimately there is a difference between conscious and unconscious sources of poor code. If it is deliberately decided to deliver suboptimal products, there is a perceived hurry to ship to market. If there is a strong enough incentive to pay the cost of rushing a product, the scenario incurs technical debt because there was a conscious decision to incur that debt. However, this post points out that often when speaking of technical debt, the poor code is not a result of expedited release but because of poor skill or lack of understanding – all in all this code is not tech debt but is sloppy code.

The post recommends speaking about whether lack of quality in code was intentional or not by calling the lack of quality “lack of craftsmanship”. When looking at source code sometimes there is a complexity present that could have been avoided if there were more time, money, or skill. This post states that figuring out the difference between sloppy code and technical debt doesn’t really matter, as the actions needed to resolve the problems caused by both are the same. As long as there is an awareness of the distinction between releasing ‘too early’ for different reasons and that there is always room to improve skills in order to avoid unnecessary complexity.

To read the full post go to: http://xlntconsulting.blogspot.ca/2014/11/why-is-programming-so-hard.html

http://www.ontechnicaldebt.com/uncategorized/why-is-programming-so-hard-incidental-and-accidental-complexity/feed/ 0
Pay Yourself First: The Art Of Reducing Technical Debt http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/#comments Mon, 17 Nov 2014 09:00:05 +0000 http://www.ontechnicaldebt.com/?p=3200 read more]]> Technical debt acts as negative interest on your time that continues to accrue while you work. Here is a post that goes beyond this definition in order to come up with a ‘pay yourself first’ technique to reducing technical debt overtime.

The example of technical debt given in this post is when in one case software is installed into one machine which only takes 20 minutes; however, if this needs to be repeated on 50 machines what seemed to be a simple and quick task multiplies in work and time required to complete. In another case, 8 hours of time is spent upfront automating the task which in the future would increase the ability to write scripts and if it needed to be installed on 24 more computers it would end up winning on time invested. This demonstrates the advantage of automation and reducing technical debt, but with debt much times already present there needs to be a method to pay it off.

The post refers to David Chilton’s book, The Wealthy Barber, in order to take the method of paying yourself first that he presents. Paying yourself first, in the financial sense the book refers to, means setting aside 10% of your pay and putting it away – which in short term won’t affect you but ” the long term net effect is great because of compounding benefits of the base amount growing”. This method can be reappropriated for the use of reducing technical debt by spending 10% of each day making changes to reduce debt currently present. This can be done by writing or improving a script to automate a process, meet with stakeholders to build better feedback loops, or spending an hour with training materials.  Asides from this technique of setting aside time daily to reduce debt, making meetings a more effective use of time is important. In a meeting there should be a person designated to writing down task and those responsible for those tasks and make sure that there is ‘meaty’ content at the heart of the meeting. 

Ultimately, the point of this post is to inspire daily reduction of technical debt which in the long term will “pay off in dividends”. To read the full post go to: http://www.discoposse.com/index.php/2014/11/09/pay-yourself-first-the-art-of-reducing-technical-debt/   

http://www.ontechnicaldebt.com/uncategorized/pay-yourself-first-the-art-of-reducing-technical-debt/feed/ 0
The Problem With “Technical Debt” And Other Agile Terms http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/ http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/#comments Wed, 12 Nov 2014 09:00:50 +0000 http://www.ontechnicaldebt.com/?p=3186 read more]]> Technical debt, as a term, serves to incentivize change within app and portfolio management. However, it fails to translate with business leaders, therefore failing to push through with the change it seeks to promote. In this post, Phil Murphy expands on his love/hate relationship with the term; lauding the “sentiment for change” it inspires, but criticizing that it does not fully express the fact that both technical and business sides of a firm suffer from technical debt.

In his defence of technical debt Murphy states that opting for expedient change over refactoring code has left app portfolios with heavy amounts of accrued debt. This daunting amount of debt ends up becoming a “self fulfilling prophecy” – as it’s too large to tackle and therefore ignored until a later date. This ignored debt ends up consuming much of the percentages that could be spent on business technology, and in the age of the costumer where quickly building mobile apps and costumer facing is highly important, technical debt serves to severely slow down change velocity.

Although Murphy appreciates the change that technical debt highlights must happen in the app and portfolio level, his ‘hate’ for the term comes from it’s inability to translate into business leaders’ language. Leading off with the word technical doesn’t do much to help motivate the business side of a firm to act on the problem (technical has to do with IT, it’s not business’ problem). Another way in which business leaders can react to technical debt is that it is debt that the technical side of the firm created, therefore it is their responsibility.

What Murphy concludes is that there is a problem of communication when it comes to technical debt. In order to resolve this, there must be an effort to avoid using jargon and to simply speak to business leaders in terms they understand.

To read the full post go to: http://blogs.forrester.com/phil_murphy/14-11-07-the_problem_with_technical_debt_and_other_agile_terms

http://www.ontechnicaldebt.com/uncategorized/the-problem-with-technical-debt-and-other-agile-terms/feed/ 0
The Broken Windows Theory of Technical Debt http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/ http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/#comments Thu, 06 Nov 2014 09:00:50 +0000 http://www.ontechnicaldebt.com/?p=3182 read more]]> Technical debt is often treated as an afterthought; teams convince themselves that they have taken into account the extra time and effort required to address tech debt in their planning, making it easy to justify carrying debt for a long time. One way to explain the side effects of carrying on small amounts of technical debt that are difficult to identify, is to compare tech debt build up to the broken window theory. Broken windows is a crime theory developed in the 1980s in which low level crimes (such as vandalism) when ignored, are followed by the prevalence of larger and more serious crimes. Broken windows set a norm of behaviour for the community, in which people adjust themselves to more criminal or antisocial attitudes. This gradually causes the neighbourhood to become more run down and dangerous.

This theory can apply to products as well. Short term solutions and dirty fixes build up in code acting like vandalism in a neighbourhood. If a code is ugly and difficult to work with adding more quick and dirty work begins to take on less significance in the developer’s mind. Subconsciously, developers lower their standards because why would they bother doing good work if it is likely to be the only good code in the project or likely to get written over? Thus, cutting corners on code becomes the broken window in the neighbourhood that leads to more serious problems in the future.  The solution to broken windows, in this post, is to fix all the windows that are already broke and make it high priority to rapidly fix and new breaks that occur – identifying the biggest problems in the code base and tackling these first. In order to prevent the reoccurrence of broken windows teams must weigh the priorities of delivering new and improved features fast vs. paying off technical debt – avoiding the build up of technical debt may mean slower delivery on new features but it also helps to build a better product.

To read the full post on technical debt and broken windows go to: http://www.mindtheproduct.com/2014/11/the-broken-windows-theory-of-technical-debt/

http://www.ontechnicaldebt.com/blog/the-broken-windows-theory-of-technical-debt/feed/ 0
Good and Bad Technical Debt http://www.ontechnicaldebt.com/blog/good-and-bad-technical-debt/ http://www.ontechnicaldebt.com/blog/good-and-bad-technical-debt/#comments Mon, 03 Nov 2014 09:00:08 +0000 http://www.ontechnicaldebt.com/?p=3179 read more]]> Technical debt is usually always referred to in a negative sense, whether it be how to avoid it or how to get rid of it. However, here is a post that distinguishes between good and bad technical debt. This post makes the point that in most systems, when graphing their technical debt curve it consistently increases over time making changes to code more difficult and lowering productivity. When thinking about the ideal tech debt curve, most people would answer to maintain zero tech debt over time, when in fact this could also slow down work as technical debt in the short term can be a savvy business tool.

Using “a mess” as another way of explaining technical debt, this post clarifies that a mess in the moment of creation in fact helps maintain the work flow. The phrase: new debt is good and old debt is bad becomes the basis for the rest of the post. This argument supports the idea that breaking large features into smaller sub features that can be completed in a few days before accumulating too much debt to clean up. Using this idea of accumulating good debt and then paying it soon after, the ideal tech debt curve would be a sawtooth pattern. The only difference is that in reality the curve would be returning to the debt baseline not zero, meaning that code is not perfect but well managed. The post also recommends, that even cleaning up after each iteration there is still likely to be a tech debt build up, and thus having a debt ceiling to keep debt from getting too out of control would be useful. Of course setting a debt baseline and ceiling is the next step so it is recommended to use a quality scale (ex. 1-5 with 1 being very poor and 5 being perfect). In the scale, there must be set limits to what is acceptable as the baseline (anything that is a 4 is at the baseline, anything lower than 3 passes the debt ceiling) and what is acceptable as the ceiling. Updating the definition of done, to a fuller concept (including tests and documentation in all code) can also help maintain a steady level of quality.

This post goes into depth of the techniques to maintain a good use of technical debt and how to stay away from bad debt (with some interesting graphics to visualize the concepts as well). To read the full post go to: http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt

http://www.ontechnicaldebt.com/blog/good-and-bad-technical-debt/feed/ 0
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