401 lecture 8

• Technical debt is the accumulated cost of incomplete or suboptimal architectural, design, coding, practices and implementation choices.
• A key characteristic of technical debt is that it arises when development teams prioritize rapid delivery over optimal, well-architected solutions.
• These teams can defer refactoring, use quick fixes, and unclear prioritization.

Technical Debt Roots

• Suboptimal technical decisions made during development leads to extra work in the future.
• Developers sometimes take shortcuts or make compromises to achieve short-term goals, often at the expense of long-term quality and maintainability leading to wrong prioritization and poor design.
• Other causes include a lack of expertise and no testing.

Technical Debt Quadrants:

• Deliberate and Inadvertent are two categories that are based on if something was done on purpose, or by accident.
• Reckless is when a team doesn't have time when in Deliberate mode or doesn't know how in Inadvertent move.
• Prudent action is when a team will deal with it later in Deliberate mode, or shouldn't have done that in Inadvertent mode.

Design Debt

• Design debt occurs when the system's architecture isn't scalable or adaptable to future requirements, leading to inefficiencies.
• A key characteristic of design debt is that it accumulates when short-term design choices are made without considering long-term scalability.
• These choices are not related to architecture, lack foresight, and are undocumented decisions.

Code Debt

• Code debt refers to messy, poorly written code that sacrifices quality for faster delivery.
• A key characteristic of code debt results from poor coding practices such as duplication or writing things like "quick fixes" to meet deadlines.
• Code debt is caused by quick fixes, lack of ownership and lack of patterns.

Test Debt

• Test debt occurs when tests are insufficient, outdated, or missing altogether.
• A key characteristic of test debt results from skipping testing phases or relying on one type of testing, and includes no unit tests as well as no test automation along with no quality culture,.

Infrastructure Debt

• Infrastructure debt occurs when the underlying systems such as servers and databases become outdated, or insufficient to meet system demands.
• A key characteristic of the infrastructure debt arises from neglecting to update infrastructure components over time, leaving them in an outdated format, missing scheduled upgrades, and an unpreparedeness for future situations.

Technical Debt Interest

• Technical Debt increases over time without maintenance while optimal maintenance is steady.

Technical Debt Costs

• Increased costs, delayed releases, reduced productivity, innovation challenges, and decreased team morale.

Addressing Technical Debt

• Managing technical debt effectively requires a balanced approach because you can't always eliminate it, but you can manage it and reduce its impact on your system.
• Improving quality checkpoints is a strategy to manage tech debt and includes things like pair programming.

Pair Programming

• Two programmers work together at one workstation. One programmer writes the code, while the other programmer reviews the code as it's written.
• Pair programming offers equal opportunity to practice skills and code ownership and can catch bug and think ahead about design.
• The motivation is to leverage the collaborative efforts of developers to produce a higher quality codebase.

Informal Review

• Developers informally review each other's code in a spontaneous, ad hoc, non-structured process, not following with specific guidelines.
• Informal reviews detect defects related to layout style and common errors, but the code is not thoroughly reviewed, just some checkpoints.
• The motivation behind this is to foster colloboration, learning and improvement within software development teams

Code Walkthrough

• Developers, architects, testers, or other stakeholders examine the code line by line or module by module and discuss logic, standards, and architecture.
• Code walkthroughs are most effective when there are quite a few reviewers with diverse background, and offers demonstration before any integratino
• The motivation behind this is to bring together multiple perspectives and expertise to improve the code.

Technical Inspection

• A systematic examination of software artifacts such as code, design documents, requirements, specifications or architecture.
• The report includes the location and severity of discovered smells, errors or defects as well as a checklist.
• The motivation is to assess its quality, correctness, and adherence to standards.
• This includes giving consistency reviewing, focus on reviewing several problems, helps less experiences reviewers and location and severity noted.

Review Short Term vs Long Term Goals

• Review short-term vs long-term goals as it's important to strike a balance between short-term goals such as meeting a deadline and long-term sustainability that includes code quality and maintainability.
• Teams should weigh those trade-offs and decide when it's acceptable to take on technical debt, or if the debt is unintentional or intentional.

Technical debt is the cost of suboptimal choices in architecture, design, coding, practices, and implementation. It arises from prioritizing rapid delivery over well-architected solutions, leading to shortcuts and compromises. Technical debt can be categorized as either deliberate or inadvertent, depending on whether it was a conscious decision or an unintentional outcome.