'Technical Debt' - Making sense of the Metaphor 

In 1992 Ward Cunningham - the man who created the first Wiki coined a metaphor called 'Technical Debt' . The term later went on to be called 'Code Debt' and sometimes 'Design Debt' . Extremely revered in software engineering circles , Cunningham was seen as a pioneer for design patterns and extreme programming. When he coined the word , he was writing financial software and tried to explain the misfeasance through the metaphor of debt to his boss . He went on to explain that attempting to write program without full knowledge to achieve short term results or perception is like taking a loan. Just as you pay interest when you take a loan , you have to regularly spend extra efforts for the correction of the temporary shortcut taken and likened this effort to interest. Malfeasance is when you do not repay interest just as you skip this refactoring of known fallacies in the system. You enjoy the short term benefits of what the loaned principal brings in without a long term plan to repay the interest.

Soon enough the term caught up with many developer communities and became a key programming concept used to define the extra development work that arises due to a temporary short term solution or quick fix applied in comparison to implementing the best overall design approach or architecture.

Inducing a Debt is most often Circumstantial than Intentional

The continuous race of Early-to-Market -Startups are often forced to induce technical debt due to business pressures . In businesses where problem solving and innovation sometimes supersede the technical relevance or skeletal architecture , the perils of scale and the magnitude of debt remain unmeasured but real.

Disruptive technology and the startups that ride on it live with the problem of rapidly evolving technology and standards around it - be it security , coding practices , communication frameworks , development and hosting platforms et all . Most of what is done is on a best-of-my-knowledge basis .

Do and See Approach - is the only way to implement since most often there are no guidelines to be followed. Code refactoring is inevitable is such situations. The blockchain startups are a good example of this - Early entrants had little or no formal documentation available and security standards were theoretical and no established test suite still exists. With time , concepts are understood better , frameworks come into being and and the risk of debt reduces.

Technical leadership and code ownership is important in FinTech. Sometimes lack of knowledge , documentation or collaboration among the team can be crippling as the codebase is bound to grow. Most great companies started out with an effective program by a great developer but to achieve scale or expand this very codebase has to be modular.When VCs look to invest , it is important to assess that the architecture is scalable and technical leadership is aware of what limitations exist and exactly when to refactor to scale.

So , Who really pays off a Technical debt ?

When a new CIO takes over or a new VC firm evaluates investment , it is important that technical debt footprint is assessed because really , it is they who land up repaying this debt.

Traditionally when banking was about in-house application building , the cost of technical debt was born by the bank. As we moved towards outsourced services , the service provider or service vendor bore the cost through piecemeal code refactoring . Then came along COTS (Commercial Off the Shelf) solutions and things got tricky. The risk of technical debt induced due to the urgency of one client was passed on to all other product clients as well. The value of debt began rising for the product company exponentially as it multiplied by the number of product installations. The CIO of the product company then becomes completely responsible for this. If there are VC's or additional investment sought at such point it simply passes on the debt to the VC.

Software Asset or Liability ?

Most argue , that passing on debt is a good thing just like it is with rolling monetary debt , but how many VCs will agree? The objective is to accelerate growth for these firms and seek favorable exits . However , the investor must understand that sometimes strengthening the foundation at the cost of expansion can mean long term results.

With new tools for scanning and assessing software assets, quality of legacy footprint can now be gauged and they also help to determine what it will cost to eliminate this debt. Quantifying the technical debt in order to understand, contain, and mitigate the debt, as well as decide how to prioritise next steps can be done through tools.

Quantifying the Debt

Accumulated technical debt can lead to decreased efficiency, increased cost, and extended delays in the maintenance of existing system and the very first step starts with assessing the size of it. There are some tools to help assess as seen below -

CAST is a software that can help to detect and correct errors in its core systems that could carry significant structural risk and thereby allows one to arrive at the monetary impact.

Some companies offer plugins to your existing code. One such example is the Sonar plugin which can uses a proprietary formula to give an approximate a dollar figure to assess the value of debt which looks somewhat like this - 

Debt(in man days) = cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold

There are also consulting companies such as Cutter Consortium who do an unbiased Debt Valuation and Assessment exercise.

Deloitte is conducting an extensive study on technical debt reversal and predicts this to be one of the top digital trends in the recent years. Back in 2012 , the firm had predicted that $3.61 is the technical debt incurred for every line of code written within a typical application whereas globally it estimates the cost of debugging software is around a whopping 312 million USD. 

Conclusion

FinTech Startups will protect precious seed capital and take shortcuts to build software and to play the catch up game or focus on innovation . Venture Capitalist firms will inherit technical debt in the entire lifecycle . It is important however , to understand the depth of the damage as well as the cost of reversal to truly measure the strength of the company.

#fintech #VC #funding #technicaldebt