Early and continuous feedback - ftw

We’re having a beautiful summer here in London.  (Update: Typical!  That jinxed it!  Sorry.) It seemed like I would have been wasting it to rush back to work.  But feet get itchy.  So I’m very excited to be starting at Conchango on Monday as a Senior Technical Consultant.  I’ve known about Conchango for a while and theirs was the first name that came to me when I was thinking about who I’d like to work with.  Agile, modern, pragmatic, talented people etc. 

One thing that’s really impressed me is the feedback that I’ve been getting during the recruitment process (thanks Michelle).  At both interviews I was given immediate feedback (including from a technical test).  That’s something that’s never happened to me before!  I’ve probably only been for a dozen interviews in my career but I’ve interviewed lots more candidates.  Always the feedback has been something that happens after the event – I’ve been as guilty of it myself. Usually over the phone or in an email a few days later. But early feedback is very important.  It makes everything clear, transparent, honest.  It prevents time being wasted and gets things moving much quicker.

In Agile we depend on early feedback.  We can’t work without it.  The whole thing breaks down if the customer is not available to let us know what’s good and bad about what we’re doing.  It helps prevent us making speculative assumptions and wasting our time.  Test-Driven Development and Behaviour-Driven Development give us early feedback – green lights everywhere for that nice fuzzy feeling.  Make it fail --> Make it pass --> Make it right --> Feel good.  Feedback makes us feel good.  Early feedback makes us feel good sooner.

At London Underground we used a product from JetBrains called TeamCity for Continuous Integration (CI).  A lot of people use CruiseControl.  I found TeamCity easier to set up (it has loads of features and the professional edition is free).  Whatever tool we use, the reason we do CI is to give us early feedback – we know immediately when the build is broken or the tests start failing.  Why?  So that we can fix it straight away.  That keeps the team working and the software quality high.

All these feedback mechanisms help prevent us from introducing bugs (or going off on tangents) – or at least they help us catch problems early – and we know how quickly the cost of fixing stuff rises the longer it takes to discover it.  The feedback helps us get it right.  Everyone wins.

Feedback should be something we do all the time.  In every conversation we ever have.  I know one thing - I’ll never interview anyone ever again without giving them honest and immediate feedback at every stage.