Welcome to technical debt. In this lecture, we're going to talk a little bit about what technical debt is and how to manage it.

Technical debt refers to the future costs that will be incurred when you decide to deploy an easy solution rather than one that's grounded in best practices. it's essentially the price you pay for bypassing best practices because deploying them takes longer to complete.

The term technical debt is used because of its similarity to financial debt. Think about it. A person who is in debt is often in debt because he often makes decisions that only consider the now. However, over time, interest accrues. As that interest accrues it gets harder and harder for that person to manage that debt in the future. Fewer and fewer options are then available to him. This snowball effect isn't much different from the snowball effect that occurs when developers make decisions without any regard for the future. Just like financial debt, technical debt will snowball to the point where developers wind up spending most of their time troubleshooting problems and doing rework. This prevents them from adding much value to the project and to the organization in general.

Increased technical debt is often blamed on tight deadlines because if a developer is forced to throw together code quickly he's often going to take shortcuts, it's only natural. For example, a developer who is under the gun to add new features to an application might simply make a copy of a specific piece of code and then edit it rather than refactoring the original method to include the new functionality. This faster way of completing the task allows the developer to only have to test the new code. He can also avoid the more stringent testing that would probably be required if he refactored the original method because it's going to be used by other parts of the code.

While this strategy does meet the deadline, it results in a longer-term problem because there are now two different copies of the same code that will need to be managed and maintained going forward. This increases the risk of the app logic diverging.

Other causes of technical debt include a lack of technical skills, a lack of product direction or ownership, or maybe an organization with no defined coding standards at all. Regardless, at the end of the day, technical debt is a main cause of projects that fail to meet their deadlines.

Because of the impact that technical debt has on delivery and maintenance of solutions, it's critical that you integrate the assessment and measurement of technical debt and of code quality as part of your continuous integration and deployment pipelines in Azure DevOps.

By building in support for things like Sonar Cloud to an Azure DevOps pipeline, you can leverage it to analyze your code. This allows you to drill down into issues that are identified. As a result, you can see what the issues are along with suggested remedies. You can even view estimates of the time that's required to apply each remedy.

By building in support for things like Sonar Cloud to an Azure DevOps pipeline, you can leverage it to analyze your code. This will allow you to drill down into issues that are identified. As a result, you can see what the issues are along with suggested remedies. You can even view estimates of the time that's required to apply each remedy, this ultimately helps you minimize your technical debt.

Lectures

Introduction - Identifying & Recommending Quality Metrics - Feature Flags - Technical Debt - Team Structures - Performance Testing - Inspecting & Validating Code Base for Compliance - Inspecting & Validating Infrastructure for Compliance - Secure Development & Coding - Infrastructure Security Validation Tools & Practices - Conclusion