How Mechanical Sympathy got me to the airport on time

Lets talk about mechanical sympathy.  Martin Thompson has been making this term very popular in software development, so it's best to read his description of why he used the term.

I had a perfect example yesterday.  I'm about to drive to the airport and the car won't move (I'm a modern tomboy, I can write stories about hair and stories about cars). Not at all.  It's stuck.  I can't reverse out of my parking space.

The first thing that occurs to me is something is stuck under the car.  Like a cat.  Those buggers hide in the stupidest of places.  So I get out and check there's nothing wedged against the wheels, which seems like the most logical thing that would stop the car moving.

(OK that's not true.  The first thing that occurs to me is oh-my-god-I'm-going-to-miss-my-plane-and-I-haven't-got-a-backup-plan-to-get-to-the-airport-and-I've-already-paid-for-parking-and-I-would-like-to-cry-now-but-that's-not-going-to-help)

Since there's nothing under the car, the next thing that occurs to me is the handbrake is stuck on - it feels like it's the rear left wheel that won't move, and I know (probably as I had a similar problem on my previous car, my lovely but ancient MX5, or maybe because I've seen far too much Top Gear) that the handbrake applies to the rear wheels.

I also suspect that the handbrake jamming this is the correct answer because I put the car through the car wash on Monday, and the known issue of the brakes jamming on some Volkswagens always manifests in my car after the car wash.  I should probably just let it get dirty.

Because I'm big on tests, and scientific theory, I test this hypothesis.  I rev the hell out of the car and force it backwards.  OK, I'll be honest - this wasn't a test.  This was a brute force attempt to unjam the handbrake. But it did provide a suitable test - when I got out of the car to inspect the offending wheel, I could see skid marks on the floor where the wheel had been dragged, rather than rolled, over the tarmac.  Oops.

So my (limited) knowledge of how a car works has provided me with a hypothesis, and reasonable proof that it's correct.

That's all fine, but I'm still not on the way to the airport yet.  How did I fix it?

What do you think I did? Well, I drove it back and forth a view times, hoping the jolting and extreme discomfort of the brake pad against a moving wheel would unlock the brake (from previous experience, the brake clicks off, rather than simply easing off).

Of course it didn't work, and I'm probably going to have to replace that tyre much sooner than expected.  Ooops x2.

I sat in the car and pumped the foot brake millions of times - a trick that either inexplicably worked on the MX5, or simply distracted me long enough and the brakes fixed themselves eventually.

This didn't work, not surprisingly (not the same brakes after all).

Finally, I got out of the car and kicked the wheel a few times.  Hard.  I figured this might jolt the brake back into position.

It didn't

Then I used my brain.  That's not going to work when you unconsciously put the hand brake on when you leave the car to kick the wheel.

So I took the brake off, then kicked the wheel.  Hard.  A lot.

And it worked!!!

And this is a bit like diagnosing performance problems (no, really).  My basic understanding of how the car was put together, plus some experience with similar problems in the past, gave me guidance on where the issue was and what might be done to fix it.

So, what have we learnt today, boys and girls?

• A basic understanding of how the hardware works can prevent you calling an expensive expert to do a simple fix.
• Always have a backup plan (Disaster Recovery/High Availability - if not hardware, then at least some sort of process).  I was much more stressed because without the car, I had to come up with a whole new transportation plan with a very limited time budget and having no knowledge of or experience with alternatives.
• I need to drive my car more, because then a) I would have either discovered the problem sooner, or b) it would never have got to that point.  I'm going to say that in this tenuous analogy, the equivalent is to do testing in a live-like environment, and actually do DR scenario testing.  Then you know how your hardware and software behaves under abnormal circumstances, and have some concept of how to get back to normal.

I did make it to the airport on time, because adding padding to your estimates is a Good Thing and gives you a bit of space for contingencies.  So this story does have a happy ending.

Here endeth the lesson.

Devoxx UK 2013

Last week was the first Devoxx UK, bringing the brand from Belgium and, more recently, France.  And I think it was a HUGE success.

Of course, disclaimers first - I was on the programme committee, so I might say that the whole thing was awesome.  Although in all honesty, even being slightly involved in the organisation of a conference is a lot of work, and you can't wait to see the back of it (and I didn't do half as much as some people).  Note to self - never speak at a conference you're on the programme committee for, it's too much work.

As a speaker and attendee though, Devoxx was really brilliant - great speakers, interesting content, awesome friendly atmosphere, good venue, parties with free drink and good opportunities to speak to people.  There were downsides: limited coffee availability, no free croissants, um... I'm really struggling to think of anything else, and none of those are show-stoppers (especially when the venue is in Islington, so you can step outside and get whatever you want).

All throughout the run up to the conference we kept hearing it was a conference "for developers, by developers" until I was nearly sick of it.  But it was a mantra that kept us on track when we were deciding on content, and it really came through on the two days of the conference.  Pretty much everyone on stage was, or had been, a developer, the talks were a good balance between "useful" stuff for our day jobs and "interesting" stuff for techies <insert joke about some being "useful" and "interesting">.  The future track excited us with things like like hacking on the Raspberry Pi, and the rest of the conference had a good mix of Java SE, EE, methodology and Other Stuff.

For me, the highlights were:

• Kevlin Henney's keynote, reminding us that Developers Are Human.  Who knew?
• Sandro Mancuso's walkthrough of OO principals, and how they apply to us in our actual day jobs.  Sandro did a good job of taking quite a dry topic, that many of us dozed through at university, and showing us why we already use these principals and how understanding them will make us better programmers.
• Mazz Mosley had an entertaining talk about the Dark Side of Agile, walking us through the agile practices in The Government and highlighting many of the unanswered questions that teams have after switching to agile.
• Colin Vipurs's talked about Test Driven Development from the trenches - he managed to give a good intro for those who might not have done it in practice, but for those who may have been doing it for a while, this a) was a good reminder of good practice and b) gave a good insight into why we do it.  On top of that, he had solid advice on how to write better tests, that we could all take home with us.
• Martin Thompson gave the talk I was attempting to give at JAX London last year - what is performance and how do we achieve high performance in Java?  Where I failed, Martin really rocked it.  I'll be leaving that to the professionals.
• It would be rude of me not to mention this point - what a diverse conference!  We had developers of all shapes and sizes, from the suits to the mohawks, of all colours, and (by technical conference standards) lots of women.  Watch the video below and I think you can see it.  I was so proud to have been a part of it.
• ...and meeting everyone.  What an awesome conference for networking!  Of course, there was a large number of London Java Community people there (speaking, volunteering, and attending), and quite a few familiar faces from Devoxx Antwerp - it was brilliant to see them in London.  But I was also very pleased to run into people I've worked with in the past, some I haven't see for ages, and some I still see regularly.  And I met dozens of new, interesting people - you guys really made the conference for me.

I was giving my new presentation, What Do You Mean, Backwards Compatibility?  In this talk I share some of the experiences I've had in helping to develop the new MongoDB Java driver.  This is not really a MongoDB talk, although there are some examples from the new driver, it's more a talk about design, and how we as developers make design decisions every day, something I don't think we recognise very much.  As always, I'll post a link to the video when it becomes available.  However, I am hoping to give this presentation a number of times this year, so if you missed it there will be another opportunity to see it.

As usual, my take-away theme from a conference is probably influenced by the sessions I attended, so is as much a function of what I think is important right now as it is an indication of what themes are emerging in the industry.  But I came away from Devoxx feeling like there's a desire to focus on the basics - the OO principals that have been around for years; the good design practices that have been written about many times; and, most of all, a reminder that developers have a difficult job - we don't simply turn requirements into code, we are constantly doing tricky stuff like system design, and even trickier stuff like working with other people.

I loved Devoxx UK, and I wasn't alone in feeling a bit empty when it was all over.  To re-live a tiny amount of the event, or get a good feel of what it was like, watch this video by the awesome Roy van Rijn.

Devoxx UK 2013 - Long mellow version from Roy van Rijn on Vimeo.

As with all Devoxx events, the talks will be available on Parleys.  If you watch nothing else, watch Kevlin's keynote.