Tag: Application

Technical debt is defined, in this post, as any code that impedes agility as a project matures. This is an important definition to keep in mind as the following attitude towards technical debt is discussed.

As business leaders become more involved with IT investment decisions many CIOs have found it more difficult to receive funding for maintenance of applications and infrastructure. The result of this is that technical debt has become an even more useful term to explain to business stakeholders the importance of IT maintenance investments. This post goes into detail on how to calculate technical debt.

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.

This article gives us an in depth look at another type of IT debt: architectural debt. It starts off with the jarring statistic that 72% of IT budgets are usually spent “keeping the lights on” or in other words day-to-day maintenance. The only way to reduce this proportion of the budget dedicated to maintenance is to address its cause.

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).

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

The topic of technical debt or the down-stream costs of careless development is one of the fastest-growing software measurements. However, as most widely calculated technical debt is alarmingly incomplete. Pre-release quality costs are usually omitted from technical debt calculations. Even worse, the very high costs of projects that are cancelled and never delivered have zero technical debt.