Technical debt is a huge problem for many organizations today and if it’s not being addressed, it’s growing. Growing technical debt takes away from funds for innovation, and instead uses it toward maintenance.

Technical Debt standards have been debated for many years. And now CISQ (Consortium for IT Software Quality) has released standard that not only measures by automates technical debt calculation in complex software systems.

Technical debt is at the top of developers pain points, and according to some this is due to a flurry of new development styles that have come into vogue. The software industry's focus on rapid application development, as necessary for business agility, has furthered the problem of technical debt. Fast implementation of containers and microservices lead to DevOps teams facing serious tech debt management issues.

A distinction that we always try to make in our posts is that there is both good and bad technical debt. This is similar to how there are ways in which financial debt can be used to strategically help a company

A while ago we published a post on IDC predictions that the bi-modal IT approach is a recipe for disaster. There are different opinions on what works in software development: those who support the siloed approach of bi-modal IT, those who urge against this division between predicability and innovation, and others who say fast development is the only way. This debate is only just beginning so it's worth while expanding on the arguments surrounding it.

There are always trade offs to be made when you're dealing with keeping your application portfolio up-to-date. You always have several options, whether it be modernization through migration/refactoring or by a sort of "transformative leap".

In software maintenance and evolution, it is important to assess both code health and application architecture in order to identify issues impeding software quality goals. One way to move the needle toward software quality is to use Technical Debt (TD) indexing as a method to evaluate development projects.

We recently presented a paper at MTD 2016, the International Workshop on Managing Technical Debt put on by the Software Engineering Institute at Carnegie Mellon, where we discussed the way five different and widely known tools used to compute Technical Debt Indexes (TDI), for example numbers synthesizing the overall quality and/or TD of an analyzed project.

There's bad news ahead for organizations that focused on a bimodal IT approach. According to research firm IDC by 2019 80% of those firms will have accrued crippling amounts of technical debt leading to increased complexity, cost, and a hit to their reputation.

Here, at On Technical Debt, we often discuss the difficulties of communicating technical debt to business stakeholders, the consequences that arise from it, and the ways to about paying it back - but in this post we are going to focus on why it is there to begin with.

Remodeling software should be done in the same mindset under which we remodel a house: to make it last longer and run better. Companies should be invested in mending their code to be able to get more productivity out of it.