Technical Debt: SPLASH 2014 Workshop Report
SPLASH 2014, Portland, OR
October 20, 2014
Workshop conclusions
Technical debt is more often "swept under the rug".
We need to think about mitigation and management, and
we need to teach others about technical debt issues.
The workshop attendees addressed the following five technical debt issues:
- How to mitigate technical debt
- How to manage technical debt
- How to make technical debt visible
- Technical debt and Agile
- What do we teach the next generation?
1. How to mitigate
We need strategies for keeping technical debt under control,
and sometimes prevent creating it in the first place.
- "Over-engineered architecture" doesn't work - we must evolve
and learn over time
Four ways to keep technical debt from growing:
- avoid duplication - especially "forking" existing code (by
copying and modifying)
- keep a list of Technical Debt issues - a kind of "technical
debt backlog"
- whether or not you use Agile, this can be a separate issue list
from the Product Backlog
- but items can be copied from the list of Technical Debt issues
into the development plans
- this technical debt issue list includes:
- duplication
- design/coding shortcuts
- test shortcuts
- experimental code
- open source updates that you
are supposed to submit back to the open source repository
- get an experienced team
- option 1: build a team with lots of development expertise (or include
some young "rock stars")
- option 2: invest in the time to learn - improve skills and
knowledge of the team
- use scenario-based modeling to supplement "feature lists"
- this helps you focus on the essential improvments
- and you think about architecture, not just delivering code
2. How to manage
We know we are going to have technical debt, so how do we live with it?
- include some technical debt work in the budget - for example,
in each release or each iteration we will spend 20% of the effort
on design and code improvements
- find problems as early as possible
- engage testers
- testers help define scenarios, and they can improve our
ability to do continuous testing (so we find issues earlier)
- in an Agile project, testers are "pigs" (not "chickens")
- include technical debt as a risk to track in the risk
management process
- note: even if you outsource the development of some components,
it won't eliminate the risk of technical debt
3. How to make technical debt visible
Two key ways to find problems:
- design reviews and code reviews (using humans to review)
- static code analysis tools (Coverity, Klocwork, Sonar, ...)
Static code analysis tools find some technical debt problems, especially in a large legacy code base.
- go beyond just counting the problems reported by static analysis tools
- look for the "design shortcuts"
- manual inspection of code - focus on class interfaces
- check dynamic references to other classes
We should prefer "peer-to-peer collaboration" to central command and control.
Collaboration supports better information sharing, and less
manipulation of metrics.
A couple of useful metrics:
- How much is your build/test/deploy cycle slowed down by technical debt?
- How long is the technical debt backlog?
We also need to look at test results:
- Run performance tests and load tests as early as possible -- analyze the
results to find the "root causes".
4. Technical debt and Agile
It is all Agile -- all projects need to react to technical debt
in an agile way.
5. What do we teach the next generation?
Get experience with technical debt
- it is impossible to learn about technical debt by doing solo development
(the most common model in education)
- need to work in 5-6 person teams
Outside of a course with teams working on a "big project", are there
other ways to learn?
- Design Fest (5-6 developers, simple design problem, 3-5 hours)
- Hackathon (learn how to do mashups)
- get some experience in refactoring techniques
Workshop attendees
- Matthew Flynn (Health Care Services Corp., USA)
- Steve Fraser (independent, USA)
- Dennis Mancl (Alcatel-Lucent, USA)
- Dan Miles (Boeing, USA)
- Marcelle Mussalli Cordeiro (Petrobras, Brazil)
- Frank Schmager (Bandwidth, USA)
- Werner Wild (University of Innsbruck, Austria)
Thanks to everyone who contributed to a great discussion!
Last modified: Oct. 21, 2014