Ivan’s agile thinkings

Just a quick post to let everyone see the latest incarnation of the big, visible build monitors that I have been building.  The current version connects directly to the network and scrapes Hudson’s json api for a specific view of the builds we have.

Here’s a list of the component parts:

• an Arduino ATMEGA328
• an Internet Shield
• code to parse the json api output of Hudson and drive the LEDs based on the status (colour) of the builds
• a few high-power LEDs to glow as brightly a possible (might whack some more in there one day to really make it glow)
• a dome (with previous lamp removed) from IKEA

This version is much prettier than the tupperware version I produced previously.  However, I did have to up the LED brightness so they can actually show through the pearlised lamp dome.

The next version will trigger a sound when the build status changes so the team knows that something’s gone wrong sooner (and that normality has been resumed when the build is fixed).

NOTE: The ‘bling bling piggy’ is always nearby to help lighten the pockets of those who break the build.

I’ve had this one sat in my FireFox tabs for months and only just got around to reading it.  Gojko Adzic lists the outcome of an openspace session at CITCON Eurpose:  http://gojko.net/2009/09/24/top-10-reasons-why-teams-fail-with-acceptance-testing/

Most of the reasons rung true with me too, especially at the start.  It’s been two years now since we adopted FIT as our acceptance test tool.  We’ve improved greatly since then, but we still have challenges.

1. No Collaboration
   Initially we had developers writing tests and proving the usefulness of the approach.  Unfortunately, the same developers were then tasks with writing a battery of tests against the existing buggy code.  It was a between-project slack period and there wasn’t anything better for them to do.  Unfortunately #2 and #10 came in to play with junior and intermediate devs mirroring the existing system in tests, rather than describing the business requirements.
2. Focusing on how, not on what
   We definitely had a lot of this going on.  We have far more procedural ‘this then this then this’ tests that have a huge amount of setup actions than I like to admit.  We have definitely turned this around somewhat more recently with more abstract ‘business requirement’ tests rather than ‘technical requirements’: the tests don’t change just because the implementation does.
3. Tests unusable as live documentation
   This is my biggest chagrin with the tests, lack of prose around the FIT test tables explaining WHY.  When there are comments they describe what we’re doing with the ‘this then this then this’ style.  Again, we have turned the corner recently but it’s a bugger to retro-fit that kind of knowledge into the tests.
4. Expecting acceptance tests to be a full regression suite
   I think I can own the blame on this one.  I pushed for this to be the case.  In my defense I did push for quick, localized acceptance tests that could run quickly and give the required feedback.  As you may guess, that’s not what we ended up with.  Rather, we got a whole slew of System tests.  They are still very useful tests, they just take longer to run that I want.  In a way it’s a reflection of the system we’re testing: very coupled system begets very coupled tests (maybe).
5. Focusing on tools
   Not really something we struggled with too much.  If anything it was the opposite – few tools in our price range.  We settled on FIT and went forward.  We also use the FitPro Eclipse plugin though it’s limited Mac and Linux capabilities are still a bit of a challenge.  We did look at FitNesse for a while and knowing what I know now I would probably have chosen that as it is more actively developed.  Our biggest perceived challenge was one of integrating with Subversion, in the end it was a non-issue.
6. Not considering acceptance testing as value added activity
   We are doing so much better than before with QA/BA developing the first example FIT tests but we’ve still got a ways to go.
7. “Test code” not maintained with love
   Another sore point for me.  Developers treat our test code as an afterthought and seem to think that good design principles and refactoring don’t apply to test code.  I couldn’t disagree strongly enough.  I am always looking for ways of making my tests simple, robust and expressive.  I often spend a lot longer on my (unit) tests than my production code.  I have hear developers whinge and complain about the test code and how “it’s hard to do such and such”.  I swear that in the time they’ve spent complaining they could have improved the test code ten-fold – but they don’t treat it the same as production code!
8. Objectives of team members not aligned
   We’re actually doing pretty well at this one, we’re a million miles from where we once were.  Our QA guys now sit with the developers and BA’s and there is a true collaborative spirit at times.  I was utterly stunned (shocked, awed, caught-out) recently when a developer said to me “I’ll just commit it and QA can find the bugs”.  I hadn’t realized that that attitude still lived on within our teams.  I guess old habits die hard!
9. No management buy-in
   This one isn’t a problem – I’ve seen too many bugs and mis-understood/implemented features and also seen the benefits of automated acceptance tests to ever go back (so’s my boss).
10. Underestimating the skill required to do this well
    As mentioned above, we definitely struggled with this one initially.  Things are improving as we get better and better with this.  I think the biggest drag was the large amount of tests and fixtures that were written without too much thought that were then copy/pasted or at least aped.

Despite our challenges I think one reason we didn’t fail was that there were several people who held the opinion that ‘failure wasn’t an option’.  We needed to a rigor to our development process: Automated Acceptance Driven Development was a large part of the added rigor.  Yes it takes longer to develop initially, but it pays for itself over and over once you get over the hump.

Currently I use that “Keyword” property of Firefox’s bookmarks to get me into the Jira projects I use at work quickly:

• Bookmark an issue in Jira: http://jira.company.com/browse/PROJ1-53
• Edit the new bookmark
• Give it a sensible name – “browse jira”
• Replace the Jira identifier with “%s”: http://jira.company.com/browse/%s
• Give it a short keyword.  I normally use “j”.

Now you can simply type the following into Firefox’s location bar and jump straight to an issue: “j PROJ2-26″.

You still have to find Firefox and pop open a new tab and such.  I was wondering if I could side-step this and use Quicksilver to jump directly into an issue.  Note that this approach should work just fine with any other browser too.

Following the instructions over at coelomi’s blog I can now jump straight to a Jira issue with very little fuss.  http://coelomic.wordpress.com/2006/01/02/quicksilver-tips/

• Enable the Web Search Quicksilver plugin.
• Copy the Jira url.
• Prepend the url with “qss-”.
• Replace the issue id with three stars “***”.
• Create a new trigger copying the url into the top box.
• Ensure the next box says “Search For” and the next box is empty.
• Assign a hot key for the trigger.

I now have the following triggers:

• Ctrl-Command-j: access any Jira issue – I provide Quicksilver with the full issue id.
• Ctrl-Command-r: access any Jira issue within a specific project – I provide Quicksilver only with the numeric part of the issue id – the project and the hyphen are hardcoded in the url.
• Ctrl-Command-b: same as the one above but for a different project.
• Ctrl-Command-g: A general google search.
• I’ll be adding another to perform a search on our wiki too.

Inspired by Neal Ford’s talk last weekend at the No Fluff Just Stuff conference in Seattle I have recently spent a little bit of time installing a bunch of utilities and setting up my MacBook Pro ‘just so’.  I’ve always hated using a mouse, it’s always so damn far away from my hands when they are settled above my keyboard.  But being relatively new to Mac OS X (I was previously mainly using Linux for about 5 years) I wasn’t aware of what could be done to prevent the need to reach for my mouse so often.

An interesting thing to note about the NFJS conference is that all the presenters were using Macs: the majority of the attendees were also using Macs.  So it was a great chance to pick up tips and tricks.

Anwho, the changes I made:

• Quicksilver – shortcuts to launching apps and sooooo much more
• OpenInTextMate – open the files or directories currently selected in Finder (Quicksilver trigger: alt-shift-m)
• OpenTerminalHere – open a terminal for the directory currently viewed in Finder (Quicksilver trigger: alt-shift-t)
• lselect – select a bunch of files based on glob expressions in Finder
• Zipeg – viewing archives without expanding them
• Global shortcut to pop-open finder – ctrl-alt-cmd-f
• Making IEs 4 Mac work with Outlook Web Access – Public Folders, Calendaring, etc.
  • Make sure you you have your WINEPREFIX pointing at the version of Wine IE is using (caught me for about an hour)
  • IE does monster my CPU, but at least I can book a meeting room myself (my team will be very happy about this)
• Grand Perspective – a tree map view of your harddrive – no productiviy boost in itself, but it allowed me to find large files I didn’t know I had and do some spring-cleaning.
• Witch – a better task switcher

Even whilst setting this stuff up I found myself naturally using the new shortcuts, so I’m very hopeful that my productivity will get a good boost for a moderate investment of time.