Is there something called Functional Debt?

Most of us are aware of the term, "Technical Debt". It simply means the code that we add in the software to solve a problem quicker by implementing some bad coding practices, which over a period of time becomes a debt, if not removed from the software. For example: Hardcoding a value in the code which is suppose to come from another system/service.

Now coming to our topic, is there something called Functional Debt like Technical Debt?.

Yes, indeed there is Functional Debt and it is not something which is widely called out in day-day work life. There are few ways to identify Functional Debts in your software.

User base/User group no longer exists

Suppose there is a tax calculation module developed inside a software for a key user group and after some years the tax calculation module was outsourced to another provider. Now, the key user group is using another software for the tax calculation.

Now the code written for the tax calculation module in the original software is not removed and the IT resources (people, database, infrastructure) are still being used to maintain the tax calculation module which no one is using.

Isn't this a functional debt?

Requirements that are no longer valid/become obsolete

This is a classic case which becomes a serious functional debt. Requirements which were once deemed valid and developed, but over a period of time become obsolete due to changes in business model, market demand, legal requirements, etc. becomes functional debts.

Many times, legal requirements requires changes to software and the old legal requirements are neither removed nor handled as obsolete, leading to IT resources getting consumed thus wasting money and increasing the functional debt.

Divestment decisions affecting common systems and applications

Large organizations, as a part of their growth strategy acquires small companies and consolidate their systems and applications with common solutions, which is good from a overall IT strategy perspective.

However, when they decide to divest, it becomes challenging to separate the systems and in the process has to remove the functionalities built specifically after acquisition. If those specific functionalities are not removed from the software, then the organization has to spend towards the IT resources unknowingly, thus increasing the functional debt.

These are some of the ways to identify Functional Debts in a software. If you know any other way, please add them in the comments.