This week I attended a webinar on "Managing Technical Debt with Agile" by Michael Hall, of Three Beacons. “Technical Debt” often comes from choosing a design approach for expedience that, over time, increases complexity and costs. The financial metaphor is that of credit: to get something now, pay for it later, but with interest — which can worsen to the point that all money (effort) is going into servicing that debt, which can never be paid off. Mike offered three areas of suggestions: how to prevent new debt from occurring, how to deal with new debt that happens, and how to bring down legacy debt:
- Stopping new debt
- Culture shift: "From this day forward, we no longer allow technical debt, unless there's a solid business justification"
- Strong and visible “Definition of Done”:
- Coding standards adherence
- Code reviews
- Complexity analysis
- Written unit tests
- 0 known bugs
- Test cases passed, automated
- Test-Driven Development (TDD): write test, fail the test, then write code to pass the test. Refactor when needed. Produces higher-quality, streamlined code
- Collaborative Designs: More whiteboard sessions on design topics, less over-reliance on subject-matter experts
- Dealing with new debt
- Debt Backlog, for debt that is business-justified
- Track DEBT by name and list work tasks associated
- Track the "commitment to fix" schedule (which sprint to resolve by)
- Keep the debt service level visible, and track debt dynamically
- “Service the Debt” Commitment
- Always include a debt item in a sprint ASAP
- Service the debt as you go! Keep it as close to $0 as possible
- "Makeup Stories": they apologize to the code base and promise to fix it!
- Non-user story work for any time you circumvented quality
- Add it to the product backlog, but make visibly different, for tracking/reporting
- Prioritize into next sprint (if possible)
- Makeup Stories - have them "adopted" by related User Stories
- Good way to insure that makeup stories get worked
- If a user story leverages the debt area, include the makeup story as part of the effort
- Dedicated sprint to service debt, or combine with bugfix sprints
- Debt Backlog, for debt that is business-justified
- Dealing with legacy/inherited debt
- Re-Do Project (total redesign and rewrite) almost never worth it, unless for new technology
- “Small Chunks” Approach
- Smaller chunks of effort done within normal dev flow
- Can work well across an API abstraction
- Often requires architectural assessment
- Risk: Can require code changes to other parts of legacy base
- 70 / 30 Rule
- 70% - new user stories, 30% - paying down legacy debt
- Best with a PO who has history with the legacy system
- Rule also works to manage new technical debt
- “While There” Rule:
- While adding a new feature, any legacy function touched must be reworked to coding standards
- Works well for support team also (while fixing bugs)
- Risk: may introduce bugs
“Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills."
– Robert C. Martin (Uncle Bob)
Would love to see
I would love to see an identification of all new projects checked in to TFS as part of sprint reviews (and broadcast to all teams when added), along with a statement of the number of Code Analysis warnings. All new projects should aspire to have zero Code Analysis warnings at the time of initial check-in. When existing projects are worked on, it would be nice to see a full count of Code Analysis warnings before work began, and after work on the story was completed... the number should ALWAYS go down, and it's not "done" if the number has gone up.
Code reviews also really help here. Part of every code reviewer's tasks should be running Code Analysis against the code, to verify that the code contains no new or "easy to fix" warnings.
Coding with ReSharper on, and working to ensure every source file you work in is as "green" as possible is another good way to prevent adding new technical debt. It's also a way to quickly fix minor technical debt, and keep our source code on a trajectory of becoming better over time, instead of worse.
Noting all the "difficult to fix" Code Analysis and ReSharper warnings is also an easy way of identifying where technical debt resides, and can be useful in identifying stories and tasks for cleaning up older technical debt. Overly complicated and complex code code, bad code organization, etc. are all identified by these inspections... and ReSharper's refactoring tools can make fixing and untagling such code much easier than trying to do it all manually.
Additionally, when existing, unfixed Code Analysis warnings are brought up at review time, it can be determined whether/how/when to fix them. Questions about how to fix them (or if they should be supressed) can be raised there, or raised to ProductionTeams, or to SoS as well... so they don't just languish with people thinking it'll get dealt with "someday"...