Tonight Amr Elssamadisy from GembaSystems presented at the XPToronto/Agile User group. There was a big turnout of almost 40 people and I think one person didn’t actually have a seat.
What follows are a series of notes from the talk without too much editing…
People’s reasons for wanting to hear about Technical Debt tonight
- People with short-term focus
- Technical Arguments
- Is it worth refactoring
- Currently living in Legacy Land
- Business value of paying down technical debt
- How? (to fix)
- Best Practices
- Root causes
Examples of Technical Debt
- I have spent 3 years building legacy code website with no unit tests.
- Code that has been copy and pasted.
- Code that is difficult to get under test: large classes, methods.
- Branching and duplication of the application.
- Duplication of functionality written by different people.
How does technical debt affect behaviour?
New requirements
- Dumbed-down solutions
- Fear of change. Not sure what will happen.
- Question to ask: How hard is work this year compared to last year?
- Splinter IT group into siloed green team
Design
- What design?
- No new design
- No changed design
- Tons of band-aid solutions
- New features need to be workaround
Defects
- Only critical ones
- Lots and time and effort in regression ? $$$
- Many bugs don’t get fixed – bad code
- Often sketchy manual testing
Maintainability
- Goes down with technical debt
- Dead core after 5 years
- Inventor’s dilemma – productivity goes down over time.
- Difficult to get new people who can work with the code base.
Why do teams fall into this trap?
People follow cost of change curve. It rises exponentially: requirements to analysis to design to test to production. Code is fragile for everyone but the author.
Test-first development makes the cost of change linear. Courage? Not needed so much since you have a test harness. Tests act as a signaling system to people working on the system that there is something they need to pay attention to.
“Programming as Theory Building” – this can only be learned through apprenticeship which is not practiced in corporate America. So what do you use? Documents don’t work – this results in a new paradigm and the level of mismatch leads to additional cost. Perhaps pairing is the new apprenticeship model.
Breaking dependencies and adding test to legacy code
Low coupling and high cohesion are main design principles. –> Get teams to agree to “do no harm” to the design
Example of adding code into a function. This will make cohesion worse.
- Take the code to be modified and move the code to a new function. (Extract method refactoring)
- How hard is it to create the main object? Probably really hard.
- So, refactor to a new class (a sprout) instead so you can create it and test it.
- And may need to create mock objects to make this work due to parameters.
- Use refactoring to aggregate related sprouts.
Read Michael Feather’s book – Working Effectively with Legacy Code.
Like most things, this is a people problem. And then we had an interesting digression into Christopher Avery’s material on personal responsibility.
