On Technical Debt http://www.ontechnicaldebt.com Online Community Thu, 28 Aug 2014 19:15:57 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.2 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 off paying of 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
Technical Debt – What it is and What to do about it http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-what-to-do-about-it/ http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-what-to-do-about-it/#comments Thu, 21 Aug 2014 09:00:14 +0000 http://www.ontechnicaldebt.com/?p=3078 read more]]> This is a post that goes over what technical debt is, and what to do about it – while drawing away from the common misconceptions of the term. The post begins by quoting the definition of technical debt by Steve McConnell: “a design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time)”.  Here the author of this post adds the caveat that the cost technical debt can also extend to affecting customer satisfaction.

The post further describes the causes of technical debt (deferring bug fixes, poor decisions, intentional shortcuts…) and that to manage the technical debt accumulated, development teams must keep a technical debt backlog in order to track the system’s current state. The post also clarifies that the payment of technical debt is not always incremental, as it is often described to be (through scheduled refactoring and maintenance of code) but can need to be paid all at once because the debt has become too much for the code to be functional.

To read the full post and learn more about the differing views on technical debt go to: http://blog.iasaglobal.org/2014/08/05/technical-debt-what-it-is-and-what-to-do-about-it/

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-what-it-is-and-what-to-do-about-it/feed/ 0
Feature Toggles are one of the worst kinds of Technical Debt http://www.ontechnicaldebt.com/blog/feature-toggles-are-one-of-the-worst-kinds-of-technical-debt/ http://www.ontechnicaldebt.com/blog/feature-toggles-are-one-of-the-worst-kinds-of-technical-debt/#comments Wed, 20 Aug 2014 09:00:48 +0000 http://www.ontechnicaldebt.com/?p=3075 read more]]> This is great post about how technical debt can accumulate when employing feature flags or toggles into mainline code as a shortcut to release. Feature flags or toggles are used to” build conditional branches into mainline code in order to make logic available only to some users or to skip or hide logic at run-time, including code that isn’t complete”.

One of the advantages mentioned of adding flags or toggles into code is that it can help reduce deployment risk through incremental release strategy. However, if feature flags are used too often and not removed once their usage has expired – they can make code brittle, harder to understand, and less secure. Feature toggles should only be a temporary deployment/release management tool. Ultimately, the purpose of these flags or toggles is to reduce risk in deployment. This post concludes that the use of feature flags should be a last choice when dealing with pushing features into production, because the failure to remove these flags could lead to difficulty in supporting or debugging a system when adding new options.

To read more about how feature toggles and flags can become a main source of technical debt go to: http://java.dzone.com/articles/feature-toggles-are-one-worst

]]>
http://www.ontechnicaldebt.com/blog/feature-toggles-are-one-of-the-worst-kinds-of-technical-debt/feed/ 0
Software Process and Measurement Cast 301: Technical Debt Essay http://www.ontechnicaldebt.com/blog/software-process-and-measurement-cast-301-technical-debt-essay/ http://www.ontechnicaldebt.com/blog/software-process-and-measurement-cast-301-technical-debt-essay/#comments Tue, 19 Aug 2014 09:00:08 +0000 http://www.ontechnicaldebt.com/?p=3071 read more]]> Here’s a podcast of an essay on technical debt that delves into the reality of using technical debt and the payment of that debt. Thomas Cagely, the host, goes on to describe the practice of documentation, auditing, standards and processes maintenance, and technical debt ‘sizing and valuing’. He mentions possible strategies to maintain software, and why technical debt cannot be ignored within an organization. Clearly spoken and well detailed, this podcast could be a great way to educate development teams on how to manage and supervise their technical debt with the tools mentioned in this podcast.

To listen to the full podcast go here: http://tcagley.wordpress.com/2014/08/03/spamcast-301/

]]>
http://www.ontechnicaldebt.com/blog/software-process-and-measurement-cast-301-technical-debt-essay/feed/ 0
Bankrolling Technical Debt: A Financier’s Guide http://www.ontechnicaldebt.com/blog/bankrolling-technical-debt-a-financiers-guide/ http://www.ontechnicaldebt.com/blog/bankrolling-technical-debt-a-financiers-guide/#comments Mon, 18 Aug 2014 17:39:02 +0000 http://www.ontechnicaldebt.com/?p=3067 read more]]> The metaphor of technical debt was borrowed from the financial sphere in order to explain this very important concept in technology. Here is a post, from WallStreet and Technology, that uses more financial terms to further clarify what technical debt is and what it entails. In this post, technical debt is defined as: ” the effort required to fix problems that remain in the source code of an application after it is released. It also represents the cost of fixing structural quality problems in an application that put the business at serious risk.”

This article goes on to define the financial metaphors it’s created to explain technical debt (technical debt bonds, technical debt yield curve, technical debt risk rating, technical debt junk bonds…), with the aim of helping those in the financial field further understand and communicate the risk that is taken on when technical debt is incurred. In using these metaphors, this article is trying to explain how technical debt could be explained if it were something that were visible and easily documented.

To learn more about technical debt and see the full definitions of some of the terms mentioned above go to: http://www.wallstreetandtech.com/trading-technology/bankrolling-technical-debt-a-financiers-guide/a/d-id/1297681

 

]]>
http://www.ontechnicaldebt.com/blog/bankrolling-technical-debt-a-financiers-guide/feed/ 0
Meta-Architecture: The Solution to Architecture Technical Debt? http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/#comments Fri, 11 Jul 2014 14:59:14 +0000 http://www.ontechnicaldebt.com/?p=3059 read more]]> One of the mantras of Agile development teams is to do “just good enough” to get the job done. This is what drives the creation of  architecture that meets the bare minimum requirements to function. But the “just good enough” mindset is an easy way to incur technical debt.

This is what the post, Architecture Technical Debt: The Curse of Agile?, addresses. The challenge of Agile teams, since they follow  the “good enough” mantra, is to have well-planned technical debt that is manageable in the future so that they can continue being Agile. But here we run into a conflict in the mindset of Agile teams. The “just good enough” attitude makes architecture messy, which inherently means you are avoiding any planning of architecture technical debt, and actually taking the time to have well-planned technical debt goes further than “just good enough” architecture – and this is seen as not Agile.

So what is the solution to this architecture technical debt problem? Agile teams believe that code cannot be complete and short-cut free in early iterations and put out what is “just good enough” for today because change overtime is a constant factor in software design. In order to get over the conflict that we’ve run into for architecture technical debt, Agile architecture must happen above the software architecture level at the meta-level. When creating meta-architecture  you’re not thinking about the architecture itself, but how it changes overtime and how to support that change by evolving the architecture. The idea behind meta-architecture is summed up concisely at the end of this post: “Building software following Agile methods isn’t enough. You must also implement architecture that is inherently Agile, and for that, you need meta-architecture.”

To read the full post and learn more about Agile architecture technical debt and meta-architecture go here: http://www.devx.com/blog/agile/architecture-technical-debt-the-curse-of-agile.html

]]>
http://www.ontechnicaldebt.com/uncategorized/meta-architecture-the-solution-to-architecture-technical-debt/feed/ 0
Effective Teams; Always Releasable http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/ http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/#comments Thu, 03 Jul 2014 15:18:24 +0000 http://www.ontechnicaldebt.com/?p=3045 read more]]> Here is a short and sweet post in a series about effective development teams. The content of the article is pretty standard technical debt overview. First, that what often prevents teams from achieving their optimal goals is their software. Software that is burdened with loose ends in the source code or where there is too much technical debt that there isn’t enough time for to pay back. The solution presented in the post, is that to prevent technical debt from sneaking in you have to write clean code.  “Code that is as simple as possible and as understandable as possible. Code that is so easy to understand that defects cannot hide in it.” This can be done through refactoring code before adding changes – and making sure the changes you make are clean.

This isn’t new information, and the post doesn’t go into depth on the subject of refactoring, technical debt, or clean code – but what was the most helpful about this post was the diagram posted on technical debt. It’s reminiscent of an economic quantity demanded vs. price level graph, but explains in clearly that to suppress technical debt, ideally the cost of change over time should be low and the responsiveness to change over time should be high. This visual representation of a term that is not usually easily explained or visualized is really a nice reference to keep in mind when trying to explain technical debt.

To read the full post go here: http://www.planetgeek.ch/2014/06/12/effective-teams-always-releasable/#more-5431

CoC vs. Responsiveness to change

 

]]>
http://www.ontechnicaldebt.com/blog/effective-teams-always-releasable/feed/ 0