As one of the organizers of Agile Tour Toronto I was thrilled with our success in attracting attendees – we sold out a month before the conference.  We decided that we would rather have a smaller conference with a good experience rather than a larger one that is more than we can manage in our first year running it.

To run the conference, we created a not-for-profit organization – Toronto Agile Software Development Community – with a mission of helping people and companies in the Toronto area with Agile techniques.  I was sad that we could not do more to help grow Agile in the community.

A few days ago, Yves Hanoulle, announced that he would like to do some training to help justify flying all the way to Toronto just for a one day conference.  I agreed to help and we are going to jointly run not one, but two workshops around the time of Agile Tour Toronto.  This will allow Yves to attend and present as well as provide an opportunity for those who can’t attend Agile Tour Toronto.  The works are:

Agile Kick Start – Monday, Oct. 19th

Agile Kick Start is for those new to agile as well as those interested in learning more about the technical pillar of Agile called XP.  We also talk about agile values, self-organizing teams, project vision, scaling agile, visual management, the famous XP game.

Agile Games Day – Wednesday, Oct. 21st

Agile Games Day provides hands-on experience with key Agile concepts through a day of learning by doing.  This includes defining business value, leadership/self-organization, and learning how to go faster using the Theory of Constraints.  If you haven’t tried before, this is a great way to learn and internalize concepts.

Why offer these sessions?

As organizers of Agile Tour Toronto, we noticed that there were a lot of people registering groups of people from their company to get basic training.  Hence the motivation for offering Agile Kick Start.

One of the things we talked about doing as part of Agile Tour Toronto was to run a games track since we know how important hands-on learning is.  Then we hit complications like finding more space, soliciting proposals and just didn’t have enough time.

Yves and I are really excited to be able to offer these workshops as a complement to Agile Tour Toronto and hope you can attend.

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 Arguements
• 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 web site 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.

1. Take the code to be modified and move the code to a new function.  (Extract method refactoring)
2. How hard is it to create the main object?  Probably really hard.
3. So, refactor to a new class (a sprout) instead so you can create it and test it.
4. And may need to create mock objects to make this work due to parameters.
5. 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.