Notes for KWRuby February 2016: Technical Debt
Declan Whelan presented to KWRuby meeting on February 17. He spoke about how to deal with technical debt in agile software projects:
- Declan is a director of Agile Alliance, who recently met in Costa Rica
- he is also co-chairing an Agile Alliance tech debt working group, which is a focus for him in 2016
Definition
- old code bases tend to have lots of debt which slows down development
- Martin Fowler described the tech debt quadrants (i.e., deliberate vs inadvertent, reckless vs prudent)
- the term was originally coined by Ward Cunningham when describing technical trade-offs to the financial people on a project
- Declan's definition is: anything in the code that slows me down
- code which does not map well to the problem domain
- badly written code, however, should not be considered technical debt (e.g., not tests, not TDD, not SOLID
- Simon pointed out that technical debt can slow down paying feature debt, and that it can change as features change over time
- Domain Driven Design(DDD) can help my continuously driving the code back towards the problem domain
Measuring
- there are various software metrics which can be used measure/estimate technical debt (e.g., various kinds of static analysis, churn analysis)
- the Agile Alliance working from is trying to develop tools for analyzing finance and risk related to technical debt in a project
- Garter wrote a technical debt report in 2010
- estimated the global cost of technical debt was $500 billion, and expected it to rise to $1 trillion by 2015
- a more informally definition could include
- how happy are you in the code
- what % of time is wasted
- what would it take to fix
Dealing with it
- increasing tech debt will increase the desire for a re-write and it is well establish that a re-write can be VERY risky
- this is something that Declan has seen in large companies
- it is a deeper problem than "our developers write crappy code"
- What are the underlying reasons?
- over time is gets hard to do fundamental fixes
- this gets worse unless there is specific push back on this
- our cognitive bias of recency bias, leads us to short term/fast solutions
- one strategy is to not offer short term/faster options to client, because they will always chooser faster
- forward looking leaders are important to choosing slower but longer term solutions
- legal liability may eventually apply some pressure
- Uncle Bob had discussed this before
- Declan did an interviewed with [Martin Fowler] and Uncle Bob at Remote Agile Conference
- maybe some big catastrophic event will precipitate this
- avoid short term project which build on underlying products
- this encourages the short term choices
- instead align team/projects to maintaining the products over the long term
- Test Driven Developer(TDD) is a useful tool for guiding your code towards the better long term choices
[Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development) has been a problem because is frequently adopted as a management practise without also adopting a corresponding technical process (i.e., Agile engineering practices, XP) such as:
- Test Driven Developer(TDD)
- Pair programming
- refactoring
- simple design principles
- passes all the tests.
- expresses every idea that we need to express
- says everything once and only once (or Don't Repeat Yourself{DRY})
- has no superfluous parts.
- collective ownership
- coding standards
- automated customer tests (or acceptance tests
- Continuous Integration
some suggestions from the audience for helping with technical debt
- business agreement
- static analysis
- explicitly organized dealing with technical debt with epics, sprints, or chore stories
- education