According to Ward Cunningham, technical debt illustrates deferred, necessary work. Technical Debt includes all those internal things that you decide not to do now, but which will seriously hamper future development if left untouched. This includes within its domain, deferred refactoring. Technical Debt does not consist of deferred functionality, except possibly in stray cases where delivered functionality is acceptable to the customer, but fail to satisfy some standard, for example, a User Interface element that does not fully comply with some User Interface standard. Fowler theorizes that if you have a piece of functionality which you need to add to your system. There are two ways of doing it, one is quick to do but is messy; it will make further modifications harder in the future. The other results in a cleaner design, but will take a longer period.
Comparison between Mess and Tech Debt
Bob is of the opinion that mess is not essentially, technical debt. A mess is just a mess. You make decisions involving a Technical debt by real project constraints. They are risky but can prove to be useful. The decision to create a mess is never logical and has its roots in lethargy and lack of professionalism, and there is no scope it paying off shortly. A mess always proves to be a loss.
What Comprises Of Technical Debt
A typical instance of acquiring technical debt in code is dealing with that huge source file. Everybody on the team knows that you require splitting it into more manageable parts, but it would result in delaying upcoming features by two weeks. Touching this component without redesigning it is adding to the technical debt of your piece of software. Any change will make the final refactoring harder and requires to be paid back later with interest. This interest you will have to pay adds to the complexity of every modification you added.
An example for Technical Debt
An instance for technical debt from the operations side of things is installing your application in only a single availability zone in your data center although you have challenging uptime requirements. Organizing a split environment, which covers multiple availability zones, is more work. It might prove to be important to delay this additional work to deliver critical features to your clients. In this case, technical debt does not occur in added complexity but higher risk of downtime.
What is not Technical Debt
Redundant complexity, filthy hacks, and unreadable code are not technical debt. There is no valid ground for introducing such a mess. If the developers are of the opinion that they do not have the patience to write simple, maintainable code, they are certainly bereft of experience and professionalism. “Single brain know-how” is another term described as technical debt. But being dependent on a single individual to run a crucial part of your application is not tech debt – it’s a big threat for your organization. Thus you can differentiate between Tech Debt and Mess. To provide further details about the project, please click here.