Managing Technical Debt Pierre G. Boutquin

Welcome!

Thank You, Sponsors!

Choosing or Not Choosing Technical Debt Agenda or Summary Layout A second line of text could go here Agenda; TALMUG; Me Debt Characteristics Discovering and Preventing Technical Debt Discussion Intro Part I Part II Part III End ???

Work Experience About Me

Programming Experience About Me

Author About Me

About today’s talk… Under Promising…

History of a Metaphor Ward Cunningham 1992

Part I: Debt Characteristics

Deliberate vs. Inadvertent Prudent vs. Reckless Debt: Good or Bad? Depends…

Faster Short Term Benefit Extra Cost Why Debt? Trade-Off…

Extra Cost (Interest) As Long as Debt (Principal) NOT Paid Off Debt Drawback Principal/Interest

Perpetual Debt Growing Interest Unmanaged Debt Aka My Credit Card

Deliberate Trade-Off: Maybe Prudent Inadvertent Debt: Likely Reckless Incurring Debt Reckless vs. Prudent

Benefits Outweigh Extra Costs Affordable Repayment Plan Deliberate Debt When Prudent?

Deliberate Decision Positive Cost/Benefit Planned, Affordable Repayment Prudent Total Debt Acceptable Debt 4 Criteria:

Inadvertent Decision Negative or Small Cost/Benefit Repayment Not Planned/Too High Reckless Total Debt Unwise Debt 4 Tell-Tale Signs

Total Level of Deliberateness Size of Cost/Benefit Affordability of Repayment Total Debt Load PART I - Conclusion Debt Criteria:

Part II: Deliberate Technical Debt Choosing or Not Choosing Debt…

Good: Deliver Early/On Time Bad: Detestable Code Ugly: The Spike Deliberate Technical Debt Why???

Maybe: Date Driven Development Yes: Feature Driven Development Deliberate Technical Debt Avoidable?

Shipping Date is Fixed Features Are Negotiable Often Less Desirable Deliberate Technical Debt Date-Driven Project

Features Are Fixed Shipping Date Is Negotiable Often More Desirable Deliberate Technical Debt Feature-Driven Project

Release Planning Tool Combines Well With Prioritization The MVP Concept “Minimal Viable Product”

Prioritization Sometimes…

Agile/Scrum: Backlog Traditional: Prioritization Needs Forethought Prioritization Key: By Business Value

M UST: Part of MVP S HOULD: High-Priority C OULD: Nice to Have W OULD: Maybe Later MoSCoW Prioritization

Part III: Minimizing Inadvertent Debt Discovering and Preventing Debt…

Process Tools Minimizing: How? 2 Angles:

Process: SDLC process: Engineering Practices Test First Development Minimizing: How? Process vs. process

Communications Technical Excellence Minimizing: Type of Tools 2 Objectives:

Standup Meeting Shared SME Design Reviews Code Reviews Minimizing: Communication Tools Tools We Use:

Unit Tests Code Contracts Static Code Analysis Adherence to Coding Standard Good Coding Practices Code Metrics Minimizing: Technical Tools Tools We Use:

Tool: Unit Tests Recommended Book: “The Art of Unit Testing”

A Unit Test is an automated piece of code that invokes the unit of work being tested and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit-testing framework. It can be written easily and runs quickly. Tool: Unit Tests Roy Osherove’s Definition:

A Unit Test is trustworthy, readable and maintainable. It is consistent in its results as long as the production code has not changed. Tool: Unit Tests Roy Osherove’s Definition (cont’d):

/// /// This test demonstrates that constructor of /// the class is creating a topic session /// when it is being given valid configuration. /// [TestMethod] public void Constructor_ValidTibcoConfig_ReturnsNonNullTopicSession() { // ARRANGE var tibcoConfig = TestUtils.CreateValidTibcoConfig(); // ACT var venomSender = new VenomSender(tibcoConfig); // ASSERT Assert.IsNotNull(venomSender.TopicSession); } Unit Test Tips: Naming Convention [UnitOfWork]_[Condition]_[ExpectedResult]

/// /// This test demonstrates that constructor of /// the class is creating a topic session /// when it is being given valid configuration. /// [TestMethod] public void Constructor_ValidTibcoConfig_ReturnsNonNullTopicSession() { // ARRANGE var tibcoConfig = TestUtils.CreateValidTibcoConfig(); // ACT var venomSender = new VenomSender(tibcoConfig); // ASSERT Assert.IsNotNull(venomSender.TopicSession); } Unit Test Tips: Design Pattern Design Pattern: AAA

Use Happy Path Factory Helper Then, Create Single Sad Path Test Both Exception Type & Message Unit Test Tips: Sad Paths Maintainability Tip:

/// /// This test demonstrates that constructor of /// the class is throwing an exception /// when it is being passed a null SslCertStoreName. /// [TestMethod] public void Constructor_nullSslCertStoreName_ThrowsException() { // ARRANGE var tibcoConfig = TestUtils.CreateValidTibcoConfig(); tibcoConfig.SslCertStoreName = null; // ACT var venomSender = new VenomSender(tibcoConfig); // ASSERT // etc, } Unit Test Tips: Sad Path Design Pattern:

Method-Level Measure Calculated from Control Flow Graph Smaller Values Better <= 25 Acceptable Code Metrics Cyclomatic Complexity

Synthesis of Three Metrics Cyclomatic Complexity Lines of Code Computational Complexity Icons Color-Coded GREEN (>20) YELLOW (10-20) RED (<10) Not Expressed in Units! Code Metrics Maintainability Index

New to Me No Best Practices To Share Yet… Code Contracts Now Part of.NET!

Partially Matter of Opinion Let Tool Decide StyleCop ReSharper Coding Standard The Final Word…

Managing Technical Debt

Questions?