Working with Technical Debt
3 likes1,020 views
The document discusses the concept of technical debt in software development, emphasizing its inevitability and the importance of managing it effectively. It highlights that while technical debt can expedite processes, it may lead to long-term consequences if ignored, and outlines strategies for identifying, categorizing, and addressing debt. Additionally, it advocates for effective communication between technical teams and business stakeholders to align technology with corporate goals and ultimately improve project outcomes.
Working with Technical Debt
- 1. WORKING WITH TECHNICAL DEBT Collaborating with the Business Steve Green /steve.p.green Chief Executive Officer @stevepgreenkc
- 2. #craftingdigital Who Is This Guy? Steve P. Green Steve currently serves as the Chief Executive Officer for Blue Rivet, a collaborative digital agency in Kansas City. My professional experience I consider code an art form, and have worked to master the craft over the last 15 years at some of the finest technology companies in Kansas City.
- 3. #craftingdigital Understanding My Bias Seth Godin One of the most-loved marketing gurus on the internet, generating 50 million views per month. I believe that building software is fun. More importantly, I view it as something worthy of mastery. “If it’s work, we try to do less. If it’s art, we try to do more.” – Seth Godin
- 5. #craftingdigital A Quick History Lesson Ward Cunningham In 1992 at a developer conference, he was the first to use the “Technical Debt” metaphor as a way to explain software decisions. “Shipping first time code is like going into debt. A little debt speeds development, so long as it is paid back promptly with a re-write. Every minute spent on not-quite-right code counts as interest on that debt.” – Ward Cunningham, 1992
- 6. #craftingdigital Towards a Definition Bad Code is Often Invisible Bad code is dangerous because it is often invisible to the business. However, expressing it as debt helps expose the problem. Stuff that is wrong with the application, even though it will pass functional requirements. Technical debt is often like a Band-Aid. It will hold the application together to get it through testing. However, it is rarely a long term solution and eventually needs to be replaced.
- 7. #craftingdigital Consequences of Ignoring Debt The code will become uncontrollable Developers will become overly specialized 1 2 3 The solution will become inflexible Staff will become demoralized and unmotivated 4 Given that the software “works”, it can be tempting to ignore the debt. However, this can have fatal consequences. By actively engaging in debt conversations, the business can ensure technology is aligned with the overall corporate strategy. Why Should the Business Care?
- 8. #craftingdigital Consider This Kitchen Technical debt builds quietly over time until it becomes unmanageable No one sets out to design software poorly; rather it happens slowly over time. Consider this messy kitchen. The designer didn’t set out to create this disaster. Instead, it happened naturally over time as the result of small bad decisions that incrementally destroyed this space.
- 9. #craftingdigital An Example in Code This is a massive SQL query from the Daily WTF called the “Query of Despair”. However, even though it is hard for us humans to understand, the computer has no problem. The “Query of Despair”
- 11. #craftingdigital Common Indications of Debt A developer’s primary responsibility is to solve “how”. If they don’t know “how”, they’ll try to work through it instead of looking for help. In order to combat this, we have to look for common indicators that problems exist. This allows us to begin identifying debt. Coders Hate Asking for Help Velocity: large decrease in the number of tasks completed per sprint 1 Stress: development team is routinely stressed during deployments 3 Production: on-going issues keep coming up even after fixes 4 Quality: number of bugs per release increase rapidly 2
- 12. #craftingdigital Start Training Your Spidey Sense Look for common “smells” that indicate possible problems. “Don’t worry about the documentation for now.” “The only one who can change this code is Bob.” “ToDo/FixMe: this should be fixed before the prod roll” “Does anyone know where we store the database password?” “I know if I touch that code everything else breaks.” “Let’s just use our QA time to finish that feature.” “The client doesn’t care, just get it done!”
- 13. #craftingdigital Finding Debt In Existing Codebases Automated Toolsets Robust development such as Visual Studio provide toolsets to evaluate code metrics. Use Code Metrics When evaluating existing projects, the following code metrics can become key indicators that debt exists. Cyclomatic Complexity Measures the number of logical branches in the code. The higher this number, the greater chance of debt. Code Coupling Measures the inter-connectedness of components within the solution. The more connected, the higher probability of debt. Test Coverage The amount of code exercised by automated tests. The lower the coverage, the higher likelihood of debt. Code Commits Frequent code commits to the same area of an application can be a sign of technical debt in that area.
- 14. #craftingdigital When is Debt Most Likely to Occur? SCOPE TIME Planned Velocity Actual Velocity Business Pressure Planned Release Full Quality Release Technical Debt Understanding when debt commonly occurs makes it easier to track.
- 15. #craftingdigital Debt Happens Naturally Software Rusts Like most technology, software can become old and rusty. Once software is released to production it can be easy to forget that it may be incurring debt naturally. As vendors update their toolsets, it is highly possible that we will gain unintentional debt. Applications that reference legacy or antiquated libraries are probably debt.
- 16. #craftingdigital The causes of technical debt can be categorized into four distinct types.How to Categorize Debt Reckless Prudent DeliberateInadvertent “We don’t have time for design.” “What’s the single responsibility principle?” “We’re just going to have to launch and make a plan.” “Next time I’ll use a new responsive design.”
- 17. #craftingdigital Always Avoid Reckless Debt Reckless and Inadvertent Reckless and Deliberate Real-World Examples These real-world examples make it easier to understand how reckless debt can occur.
- 19. #craftingdigital Why Should The Business Manage Debt? The business is not motivated by… The business is only motivated by outcomes, not technical details. If a piece of debt has a negative impact, discuss that with the business in non-technical, monetary terms. “The Code Is Crufty”
- 20. #craftingdigital How To Talk About Debt In order to fully engage with the business, we must always express technical debt in monetary terms. A good strategy is to use the application’s maintenance budget as a gauge for the impact of technical debt. Talk About Debt In Terms of Money This often requires the development team to immediately estimate the time to resolve debt as it is incurred.
- 21. #craftingdigital How To Payoff Debt It’s a Business Decision No matter how much we wish it wasn’t, remember that the decision to substantially refactor is always a business decision. There Are 3 Options: There are three different strategies that you can employ when evaluating how to pay down your debt. Debt Repayment – refactor the entire “not- quite-right code” into something better. Debt Conversion – replace the problem code with a “good, but not perfect” solution. Interest Only – choose to live with the costs of the debt. 1 2 3
- 22. #craftingdigital Consider This Example Most of us would probably say “it depends”. Is it raining? How far do you have to go? There are a bunch of variables that would determine if the solution, though not ideal, is adequate. Is This a Good Solution?
- 23. #craftingdigital Consider This Example What would a debt repayment look like? Well, the best solution given our limited space might be to simply unpack the box and load the smaller contents into the car individually. Debt Repayment
- 24. #craftingdigital Consider This Example What might debt conversion look like? We could try to make the current situation a little better by providing padding on the arm rest and securing the box with the sunroof. Debt Conversion
- 25. #craftingdigital Consider This Example What would an interest only solution look like? Well, we would just choose to deal with the current situation without making any changes. We just deal with the fact it’s not the best solution. Interest Only
- 26. #craftingdigital Segregate Debt User Stories Use a separate debt backlog Creating a backlog for debt items that is separate from features provides an easy way to catalog your technical debt. Use a Kanban Board A Kanban or task board can be a great way to visualize and track the technical debt you build during an iteration. Centralized place for developers to log debt Provides a clean separation between debt and features Makes the debt accumulation completely transparent and visible Provides helpful insights when compared to the feature backlog
- 27. #craftingdigital Don’t Ignore the Debt You’re Still a Professional If you’re not active in managing your debt, your solution will begin to look like this. Actively look for ways to pay debt Ignoring the debt will eventually create a huge mess. Instead, provide developers easy ways to pay down debt. Allocate a Buffer Task This is a shared task or user story provided for each iteration where developers can log their effort for small refactorings or improvements. Use Clean-up Releases A purely technical release can be used to cleanse the codebase. These are most helpful immediately following an aggressive or hectic development period.
- 28. #craftingdigital Enforce a Definition of Done What does “done” really mean? “Done” can mean different things across all project constituents. Is it “code complete”? Has it been tested? Has it been reviewed? What about UAT? What is a “definition of done”? A definition of done is a list of tasks distributed to the entire team that clearly states when something is “done”. It should include: Completeness Unit Tests Code Review Integration Tests Documented Approved
- 29. #craftingdigital Build a Healthy Debt Culture The Most Important Question: “Why” Remember that the goal of the code review is to learn and teach. We want to encourage intentional coding. Always in person with the whole team, usually at the end of the sprint. Only review the commits in that sprint, but everyone comes prepared to discuss. Author start with something their “proud” of and something their “ashamed” of. Avoid the mundane items that can be caught by static code analysis or tests. Encourage an atmosphere that celebrates code. Mob Code Reviews: It’s Not About Quality Code reviews are the most under utilized tool an architect can use to foster team building and learning.
- 30. #craftingdigital Refactoring Your Debt Refactoring is a natural part of the development process and should be encouraged. Refactoring Is Not a Dirty Word 1 Current Context: Are you currently working with the code? 2 Comprehension: Can you easily understand or change the code? 3 Test Coverage: Do you have sufficient test coverage to support the change?
- 31. #craftingdigital Great Coders Love to Refactor Watch Out for This Guy While refactoring is natural, we must be aware that some coders just want to re- write everything. Understanding that building software is like writing a book shows us that technical debt is a natural part of the process. Developers are often self editing to remove small amount of debt, even if they are doing it without realizing it. Refactoring is an expected part of coding.
- 32. #craftingdigital Refactoring Goals Improve the Overall Design Improve Readability Reveal Or Isolate Defects Improve Efficiency and Organization Why Should You Refactor? When refactoring, it is important to keep these primary objectives in mind: Refactoring Should Be Incremental To prevent refactoring from becoming dangerous, it should always be systematic and incremental. Pain Driven Development
- 33. #craftingdigital Why Is Refactoring So Important
- 34. #craftingdigital Maximize Signal-To-Noise Ratio What is “Signal”? Signal is anything in your code that has meaning or value. If it doesn’t provide value, then it’s just noise. Use the TED Rule Signal is any logic that follows the TED rule. Terse: code should not be overly wordy. Expressive: it should be clear what the code is trying to do. Do One Thing: code should have a clear responsibility, and it should do it well.
- 35. #craftingdigital Identifying Noise Noise is in competition with signal. Below are some examples of common noise patterns in code. Huge Classes Long Methods Repetition No Whitespaces High Cyclomatic Complexity Excessive indentation Overly Verbose Names Matter Name selection has a huge impact on readability. Remember, it’s about conveying intent.
- 37. #craftingdigital Refactoring Techniques Composing Methods: The refactoring techniques in this group streamline methods, remove code duplication, and pave the way for future improvements. Moving Features: These refactoring techniques focus on safely moving functionality between classes, create new classes, and hide implementation details from public access. Organizing Data: These refactoring techniques help with data handling, replacing primitives with rich class functionality. Another important result is untangling of class associations, which makes classes more portable and reusable. Simplify Conditionals: Conditionals tend to get more and more complicated in their logic over time, and there are yet more techniques to combat this as well. Simplify Method Calls: These techniques make method calls simpler and easier to understand. This, in turn, simplifies the interfaces for interaction between classes. Dealing with Generalization: Abstraction has its own group of refactoring techniques, primarily associated with moving functionality along the class inheritance hierarchy, creating new classes and interfaces, and replacing inheritance with delegation and vice versa. See: https://sourcemaking.com/refactoring
- 38. #craftingdigital Be Part of the Solution “Always leave the code you’re editing a little better than you found it.” – Bob Martin The Boy Scout Rule When teams accept the responsibility for the design, the system as a whole improves over time. As the software evolves, developers take an active approach to enhancing the system. Much like picking up trash on the side of the road, if everyone does just a little bit, the highway remains clean for everyone.
- 39. #craftingdigital Accept No Broken Windows
- 41. #craftingdigital What’s Up? Huh? Technical Debt is Good… Technical Debt is a phrase frequently used to describe negative artifacts that occur during the completion of a development cycle. Debt is: Bad Stuff in Our Code Technical Debt is a metaphor used to explain what happens during a project that non-technologists can easily understand. It is Also: A Way to Communicate The technical debt concept is really two related, but separate ideas.
- 42. #craftingdigital The Power of a Metaphor Finding Common Ground It is often easier to explain complex ideas using analogies, especially when communicating across professional disciplines. Perspective Matters Technologists and business stakeholders have fundamentally different perspectives. Using a common metaphor can improve communication between them. Technology thinks in terms of black/white Technologists view the world in binary. Things are either right or wrong, red or green, on or off, 0 or 1. It either works or it doesn’t. Business operates in infinite shades of gray Stakeholders view the world as a series of options. Delivery can be a varied mix of perfect and adequate solutions.
- 43. #craftingdigital Using Debt As a Tool Remember, It’s About Value Accruing responsible debt is perfectly acceptable as long as your getting adequate business value When can debt be good? When actively managed, introducing strategic technical debt into a project can become a powerful tool to achieve business objectives. Decrease time to market Introducing debt can shorten the amount of time it takes to release a solution. Maximize operating capital Strategically accruing debt can allow the business to prioritize tasks according to value. Delay development expenses It is sometimes necessary to defer high development costs until a later date.
- 44. #craftingdigital Employ Strategic Design All parts of a system can’t have the same high level of quality. Therefore, the team can actively decide which parts of the system can accept lower quality. Do all parts of a system have the same quality?
- 45. #craftingdigital “Avoid being a perfectionist in a world of finite resources.” - Forrest Shull
- 46. #craftingdigital Perfection Is the Enemy of Innovation What is Innovation? Innovation is one of the most over used words in our industry. For me, innovation is the ability to use technology in unexpected ways. Stop Perfecting, Start Innovating In order to innovate, you have to be willing to make mistakes. If you spend too much time perfecting, you are likely missing more important opportunities. What the business thinks is innovative seems simple to a technologist. Furthermore, what is innovative to a technologist is often meaningless to the business.
- 47. #craftingdigital Prove You’re a Good Coder The Power of Perfection A king once asked a painter, “prove you’re a good artist”. After contemplating, he stood quietly over a piece of paper and drew a perfect circle. What Is the Most Innovative Thing You’ve Built? In a job interview, I was once asked what was the most impressive thing I’ve ever made. I love data structures, so I answered: a non-recursive red-black tree.
- 48. #craftingdigital
- 49. #craftingdigital Session Takeaways The technical debt metaphor is a powerful tool that can close communication gaps. The ensures that both technology and the business are fully engaged in the discussion. Debt Is a Tool The simple truth is that no one is perfect. Technical debt is going to happen, it’s unavoidable. However, if we’re smart about how we use this knowledge, we can make it work for us. No One Is Perfect The solution isn’t just the responsibility of the technical staff, but also the business. Allowing them to engage during the full lifecycle ensures joint ownership of project decisions. It’s Everyone’s Responsibility
- 50. #craftingdigital Next Steps Remember that a little knowledge can be dangerous. To be a great developer, I highly recommend these resources to guide you towards deeper understanding. “If it’s work, we try to do less. If it’s art we try to do more.” – Seth Godin
- 51. BE BOLD + DO GREAT WORK steve.green@bluerivet.com @stevepgreenkc /stevepgreen