Tag: Technical Debt

This method allows to prioritize those areas that present the greatest risk of business disruption or areas that cost the most to maintain.
How To Calculate Technical Debt: A Top-Down Approach
Paying off technical debt, according to this post, can be made easier with microservices architecture. When building a code base, eventually, trade-offs between quality and delivering on time will arise. The benefit of trade-offs in software is that the option to later go back and fix these shortcuts is available. Quick and dirty shortcuts and expedient design decisions build up over time and create technical debt, which needs to be paid pack before it reaches unmanageable levels. This entails refactoring bad code and reviewing questionable design decisions before defaulting on the debt created. Once the debt has been defaulted on, things start breaking all over the code base and makes working almost impossible.
Microservices Architecture & Reducing Technical Debt
This is a post that discusses an alternative to the metaphor of technical debt for ‘bad code’. The problem with technical debt as a metaphor is that for managers debt can be a good thing – it can required for financial needs or encouraged by tax breaks in certain financial situations. However, the debt that is often spoken about in codebases does not fully capture the risk that comes along with writing short cuts.
Bad code isn’t Technical Debt, it’s an unhedged Call Option
In this presentation by Kimber Lockhart, as part of the Hack Summit (the virtual conference for programers), she discusses what to do once you’ve inherited bad code. She speaks less about the source of bad code (low budget, high pressure to meet deadlines, company’s decision to hire poor developers) and more on the steps to fix and prevent this code. She does mention that not all bad code is because of technical debt, since for her tech debt comes from a conscious decision to write poor code, but this presentation does address how to get rid of it.
Inheriting Bad Code: How to Fix and Prevent it
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.
Why is Programming so Hard? – Incidental and Accidental Complexity

Gartner report highlights “application development managers need new ways to demonstrate and communicate the business value of software quality for innovation projects.”

IT Needs New Ways To Talk About Quality!
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.
Technical Debt, Technical Liability, and Moral Hazard
Anyone whose professional life has intersected with the technical debt metaphor knows its power: the simple proposition that such a thing exists opens up a new channel of communication among groups (IT and application developers, designers, biz dev) that famously have trouble communicating about technical decisions. Not everyone understands test cases, aging platforms, crufty code bases, or security loopholes, but everyone understands debt (needless to say, most everyone has personal debt, and a sizable proportion of the news media conversation concerns debts, mortgages, and deficits).
Can Technical Debt Be Quantified? The Limits And Promise Of The Metaphor
Steve Garnett from Ripple Rock (an IT consulting company that assists customers in improving their software development capabilities) is one of many who has experienced Technical Debt on a project he worked on in the past. His new blog post captures a common problem: you know the Technical Debt is there, you know that it’s going to be difficult to fix… so how do you convince management that you need the time and resources to deal with it?
Prioritizing Your Technical Debt
This interview will focus on the ground-level steps that should be taken in order to help IT teams deal with their Technical Debt in a pragmatic and efficient way, while working in a fast-paced Agile environment.
Pragmatic Ways for Your IT Team to Deal with Technical Debt
This debate will focus on addressing the viewpoints expressed by the founder of the term “Technical Debt,” Ward Cunningham, and those of Capers Jones, which take on a much wider economic approach to the topic.
Technical Debt Debate, with Ward Cunningham & Capers Jones

Risk detection is about identifying any threat that can negatively and severely impact the behavior of applications in operations, as well as the application maintenance and development activity. Then, risk assessment is about conveying the result of the detection through easy-to-grasp pieces of information. Part of this activity is about highlighting what it is you’re seeing while summarizing a plethora of information. But as soon as we utter the word "summarizing," we risk losing some important context.

Is Every Part of the Application equal when Assessing the Risk Level?

My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

Mozzilla Thinks Crashes are a GOOD Thing...Really?

Any advocate for better software quality knows that one of the biggest challenges is helping the CIO reach the CFO. When your team needs a budget for an important project, those conversations often break down. Thanks to the unavoidable technical complexity of IT, oftentimes the CIO might as well be speaking Esperanto to the CFO.

The Tech Babel Fish for CFOs
When operational requirements are ignored, using agile can easily bring on technical debt. A recent blog post on Codovation from Bastian Buch describes that even though it might be impossible to avoid technical debt altogether, there are 5 effective steps to help reduce and control it
5 Steps to Reduce Technical Debt When Using Agile

I have been an East-Coaster all my life. I’ve lived, worked and even attended college in states that all lie East of the Mississippi. However, throughout my 18 years working in the technology business, my clients have been spread out around the U.S. and abroad. I’ve found myself doing phone calls before the sun rises and well after it has set. That’s just the way it is in this business.

The Personnel Side of Technical Debt