SENG 401 Software Architecture: Technical Debt PDF

Lecture & SENG 401 – SOFTWARE ARCHITECTURE TECHNICAL DEBT Dr. Ronnie de Souza Santos https://www.drdesouzasantos.ca/ TECHNICAL DEBT THE ACCUMULATED COST OF INCOMPLETE OR SUBOPTIMAL ARCHTECTURAL AND DESIGN DECISIONS, CO...

Lecture & SENG 401 – SOFTWARE ARCHITECTURE TECHNICAL DEBT Dr. Ronnie de Souza Santos https://www.drdesouzasantos.ca/ TECHNICAL DEBT THE ACCUMULATED COST OF INCOMPLETE OR SUBOPTIMAL ARCHTECTURAL AND DESIGN DECISIONS, CODING PRACTICES, AND IMPLEMENTATION CHOICES. DEFERRED REFACTORING QUICK FIXES KEY CHARACTERISTIC Technical debt arises when development teams prioritize rapid delivery over optimal, well-architected solutions. UNCLEAR PRIORITIZATION TECHNICAL DEBT ROOTS WRONG PRIORITIZATION POOR DESIGN EXTRA WORK IN THE FUTURE DUE TO SUBOPTIMAL TECHNICAL DECISIONS MADE DURING THE DEVELOPMENT PROCESS THAT HAPPENS WHEN DEVELOPERS TAKE SHORTCUTS OR MAKE COMPROMISES TO ACHIEVE LACK OF EXPERTISE NO TESTING SHORT-TERM GOALS, OFTEN AT THE EXPENSE OF LONG-TERM QUALITY AND MAINTAINABILITY. DEBT TECHNICAL DEBT ROOTS DESIGN DEBT OCCURS WHEN THE SYSTEM'S ARCHITECTURE IS NOT SCALABLE OR ADAPTABLE TO FUTURE REQUIREMENTS, ARCHITECTURE CHOICE LACK OF FORESIGHT LEADING TO INEFFICIENCIES. KEY CHARACTERISTIC Accumulates when short- term design choices are made without considering long-term scalability. UNDOCUMENTED DECISIONS CODE DEBT REFERS TO MESSY, POORLY WRITTEN CODE THAT SACRIFICES QUALITY FOR FASTER QUICK FIXES OWNERSHIP DELIVERY. KEY CHARACTERISTIC Results from poor coding practices, such as duplication, or writing "quick fixes" to meet deadlines. LACK OF PATTERNS TEST DEBT OCCURS WHEN TESTS ARE INSUFFICIENT, OUTDATED, OR MISSING ALTOGETHER. NO UNIT TESTS NO AUTOMATION KEY CHARACTERISTIC Results from skipping testing phases or relying on one type of testing. NO QUALITY CULTURE INFRASTRUCTURE DEBT OCCURS WHEN THE UNDERLYING SYSTEMS (E.G., SERVERS, DATABASES) BECOME OUTDATED OR INSUFFICIENT TO MEET OUTDATED MISSED SYSTEM DEMANDS. INFRASTRUCTURE UPGRADES KEY CHARACTERISTIC Arises from neglecting to update infrastructure components over time. UNPREPAREDNESS TECHNICAL DEBT INTEREST TECHNICAL DEBT COSTS INCREASED TESTING COSTS REDUCED PRODUCTIVITY DELAYED RELEASES INNOVATION CHALLENGES DECREASED TEAM MORALE BLACK HISTORY MONTH: CLARENCE ELLIS CLARENCE ELLIS (1943 – 2014) First African-American to earn a Ph.D. in Computer Science, co-developed the operational transformation algorithm, enabling synchronized real-time collaboration in distributed systems, transforming collaborative editing in software engineering. ADDRESSING TECHNICAL DEBT MANAGING TECHNICAL DEBT EFFECTIVELY REQUIRES A BALANCED APPROACH. YOU CAN’T ALWAYS ELIMINATE TECHNICAL DEBT, BUT YOU CAN MANAGE IT AND PAIR PROGRAMMING INFORMAL CODE REVIEW REDUCE ITS IMPACT ON YOUR SYSTEM. KEY CHARACTERISTIC Improving quality checkpoints is a strategy to manage technical debt. CODE WALKTHROUGH TECHNICAL INSPECTION PAIR PROGRAMMING TWO PROGRAMMERS WORK TOGETHER AT ONE Equal opportunity to WORKSTATION. ONE practice skills and code PROGRAMMER WRITES THE ownership CODE, WHILE THE OTHER PROGRAMMER, REVIEWS THE CODE AS IT'S WRITTEN. MOTIVATION Catch bugs as they Leverage the collaborative happen and think ahead efforts of developers to about the design produce higher-quality code INFORMAL REVIEW DEVELOPERS REVIEW EACH OTHER'S CODE IN A SPONTANEOUS, AD-HOC Detecting defects related CODE REVIEW, NON- to layout style and STRUCTURED PROCESS, common errors NOT FOLLOWING SPECIFIC GUIDELINES. MOTIVATION The code is not Foster collaboration, learning, thoroughly reviewed, and improvement within just some checkpoints software development teams. CODE WALKTHROUGH DEVELOPERS, ARCHITECTS, TESTERS, OR Effective when there are OTHER STAKEHOLDERS, quite a few reviewers with EXAMINE THE CODE LINE diverse background BY LINE OR MODULE BY MODULE AND DISCUSS LOGIC, STANDARDS AND ARCHITECTURE MOTIVATION Demonstration before Bring together multiple any integration perspectives and expertise to improve the code. TECHNICAL INSPECTION SYTEMATIC EXAMINATION Report records with OF A SOFTWARE location and severity of ARTIFACTS, SUCH AS discovered smells, errors CODE, DESIGN or defects DOCUMENTS, REQUIREMENTS SPECIFICATIONS, OR ARCHITECTURE. MOTIVATION Process guided by Assess its quality, correctness, guidelines and checklist and adherence to standards TECHNICAL INSPECTION CONSISTENCY IN THE REVIEW FOCUS ON SEVERAL PROBLEMS HELPS LESS EXPERIENCED REVIEWERS LOCATION AND SEVERITY NOTED TRADE-OFFS: WHEN IS TECHNICAL DEBT ACCEPTABLE? REVIEW SHORT-TERM VS LONG-TERM GOALS It’s important to strike a balance UNINTENTIONAL between short-term goals (e.g., TECHNICAL DEBT meeting a deadline) and long- term sustainability (e.g., code quality and maintainability). Teams should weigh the trade- offs and decide when it’s acceptable to take on technical debt. INTENTIONAL TECHNICAL DEBT QUESTIONS? SENG 401 – SOFTWARE ARCHITECTURE TECHNICAL DEBT Dr. Ronnie de Souza Santos https://www.drdesouzasantos.ca/