- Convened by Agile Coach finding it hard to coach teams on technical practices (TDD, pairing, etc.) which he understands theoretically, but without the hands-on technical cred that someone with a technical background would have.
- Mike Bowler described a game using Lego to demonstrate the cost of technical debt.
- See full description on his site: http://www.gargoylesoftware.com/ex/technical_debt. Please send him feedback if you try his games!
- Highlights value of "clean as you go" coding.
- Sometimes illuminates danger of overpreparing, trying to foresee every future problem.
- Very powerful to include management, who can experience pain of tech debt hands-on.
- People walk away knowing, "When I took the time to clean my code along the way, I went faster."
- Important note: when Mike has run this in the past with some participants and some observers, he found that the light bulb did not go off for observers. Get everyone participating in this one!
- We spent a bunch of time discussing a messy kitchen as a metaphor for tech debt:
- The longer you avoiding cleaning up, the more painful it is to do.
- When you don't clean as you go, your efficiency is undermined by losing access to key resources (counter space, sink, specific utensils that are dirty).
- Group noted the important distinction between (a) what is needed to recover from ignoring tech debt and (b) what is needed to prevent taking on new tech debt.
- Llewelyn Falco described an activity he's used with teams:
- Look through code with team and find paragraphs–blocks of code the seem to go together.
- Ask team to extract those as a method and rename (available as keyboard shortcut in most IDEs).
- If team doesn't know what it does, call the method iDontKnow. Explore/discuss/refactor until you know clearly what it does, and rename appropriately.
- One good question for seeking out bad methods: ask team, "What method do you fear?"
- Llewelyn also discussed the value of code complexity metrics. One place he has found them especially helpful is in reporting to management what might otherwise show no visible effect: e.g., deleting an unnecessary 10% of a code base may yield no immediate apparent benefit, but clearly simplifies future development/maintenance.
- On simplicity: Mike Bowler described game: throw Lego out on a table and ask people to build a person and a house, then discuss:
- How much more simply they could have gone. Couldn't a single block represent a person?
- What assumptions underpin their move to build a representative person?
- If they were to build a simpler house/person, would that make things easier/harder in the future?
- Mike also discussed an even simpler exercise: completely clear the space in front of you on table. Say, "This is the perfect program. Why?" Discuss that it is free, has no bugs, no TD. Talk about what happens when you begin to code. Talk about how to keep as close as possible to that ideal state. How small can you make it?
- Someone said "a good coder is a lazy coder".
- General notes about coaching teams to try new technical practices:
- One person talked about experiences with people saying they don't want to do TDD when they haven't tried it. His response was to tell teams "We are here to learn how to ride a bike, not to discuss the merits of biking relative to walking. Once you know how to bike, we can have that discussion."
- Someone brought up sculpting clay vs. marble to highlight the mindset shift required of people who are not used to working in certain ways. If you talk to someone who has always sculpted in marble about techniques you use in clay, their habits of working in marble will make working in clay conceptually challenging. For example, they in marble you can't decide after the fact to add an arm on a torso, while in clay you can.
- Other links/exercises mentioned:
- Ping pong pairing: http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
- Pairing game – "Evil pair variation": write code that passes the test, but doesn't do what it should. Forces you to think about how your tests can be gamed.
- Gilded Rose kata – (Search web for this exercise available in various languages.)
- Cyberdojo.kom – gives you katas with environment to play
- koans – little unit tests that work but fail, you fix code to make them work. They come in series of increasing complexity.
- Code Retreats – Amos King talked about these. Go somewhere–preferably offsite–and spend a day, a weekend, on a fun project. Use it as a chance to try things, practice skills, compare different solutions to the same problem. (I believe this site summarizes the same thing Amos was discussing: http://coderetreat.org/).
