chris clarke

Driving in to Trouble

Testing edge cases.

Every time I run in to something that gets in my way, slows me down or just annoys me I write it down on a card. If I run in to the same problem again - I add another notch to the card (like a tally). A colleague has a principle of Three Strikes and You’re Out - that is, if you come across the same problem three times you have to fix it. I also find it useful to take these cards along to retrospectives or stand-up meetings. Fixing these things that get in the way has really had a positive effect on productivity and made the team more interested in fixing bad things rather than taking the extra time and effort to work around them.

Retrospective: Storyboard

In order to come up with some working practices for Storyboard 2 - I’m going to hold a quick retrospective of Storyboard 1 right here - a Blog-o-spective.

What went well?

• Easy to use
• Fun look and feel
• Easy to deploy
• Quick initial development
• Introduction of XML

What did we learn?

• Ajax apps are hard to test
• Having output not being logged or logged to different places is bad
• Integration tests between python and javascript are hard to write
• Tests between front and back-end are definitely needed
• Development is easiest when tests are easy to write and can drive features
• Too much client-side processing in javascript slows things down (duh?)
• Writing ajax stuff without a library is very fragile
• There’s plenty of libraries/frameworks for both Ajax and DHTML stuff.
• Storyboard without a zoom feature or different views is not useful because you can’t see all the cards easily.
• Building cross-browser compatibility from the start would have been much easier
• In fact a lot of things could have been much easier if they had been done from the start especially logging & integration tests

What should we do differently next time?

• Need a framework/way of writing tests quickly and easily e.g. Google Web Toolkit
• Make more use of ready-made libraries e.g. YUI
• Maybe use something other than python for back-end
• Have better test coverage - back, front and integration
• Prioritize features e.g. zoom feature should be high prioirity
• Have an agreed set of practices/prejudices from the start e.g. Log to one file

What still puzzles us?

• Why I did things differently than I would have done in a pure Java project e.g. no TDD from start
• Why CGI and Ajax stuff can just go wrong but not tell you why
• Why there aren’t more standard or popular libraries for JavaScript

Some Storyboard Working Practices

1. Progress will be measured in running tested features. Features will be documented via the test code. The progress will be displayed on a infinite burn-up chart.
2. All ideas & feature suggestions will be recorded and prioritized in a backlog.
3. No code shall be written without first searching for some code which does what is needed easily.
4. Any relevant output, logging or debugging information will be appended to one file: The Log.
5. Test driven development.
6. For a piece of code to be considered done done it will be Tested, Refactored & Integrated. (Refactored practices: No methods > 10 lines. No classes that break the scrolling rule (~40 lines in Eclipse).)

Cool ideas

Found a few cool ideas following rachel’s blog, including silly hats for broken build. Also, liked the use of a status, such as ‘In Progress’ or ‘Customer Preview’ for each story on planning boards.

Having a further look around I found a fellow James-Shore-fan, who had come up with a interesting idea to be used at the end of a retrospective - a ROTI (Return On Time Invested) histogram.

retro-active-spectives

I like the idea of retrospectives but I find them quite painful at times and they never seem to result in many actions actually being actioned. So I came up with a retro-active-spective, based on an idea someone called Arlo? (forgot link) had of an emotion box where people put cards in a box when they get mad or happy.

retro-active-spective

1. Everyone collects cards during the iteration - each one is written as a record of when something puzzles you, you learn something, you get annoyed or you feel something has gone well.
2. At the end of the iteration all the ‘good’ cards - the ones where something was learned or something went well are displayed as an altar in a prominent position in the workspace - a place for appreciation and guidance. (Also read them out at the start of the RetroActiveSpective).
3. Split the team into small non-natural-affinity groups and each group picks a single puzzle/annoyance and comes up with an action. (Not all of them can possibly be resolved - the groups will hopefully pick one’s which reflect the team’s prioirities.)
4. Bring everyone back together and assign a pair to the action, an owner and a chaser, give them estimates and display them as stories for the next iteration in the workspace.