Tag Archives: test driven development

Attention to Quality gets Results

Most managers, and some ‘Agile’ coaches, I encounter shudder when the subject of quality comes up.  They think quality hampers delivery.   In some ways they are right, you do want to achieve balance, avoiding polishing too much because it can cause being late in delivery  (in mission critical projects it may be better to over polish if the cost of failure is high).

Some managers may shudder because, ooops I may have been found out and I’ve been pushing my teams to push out code which is not really ready.

Other managers, maybe the inexperienced ones but not always, have no idea what quality is.  They tend to believe the lies their development teams’ say when they say it’s ‘unit tested.’

As a manager, quality is one of if not your biggest concern.  Addressing quality is an economic concern as well and managers are responsible for economic outcomes.  Bad quality will slow down your team.  But not just that, it will also slow down your organisation.

How does this occur?  How does it slow down your organisation?  Well I’ve seen this time and time again when I come to a new client.   Work is at a stand still and when I dig a bit deeper I see the same issue appear.

Yes, teams are overwhelmed with work.  So limiting WiP will help.  Using workflow mapping and lean techniques will identify bottlenecks.  Yes address those.   Importantly, in the bottlenecks I find that the reason for those delays is the negative feedback of poor quality.

I see upstream, product ideas waiting to be developed and tested with the customer because there is a wave of poor quality slowing down the delivery pipe.   Overwhelmed with defects teams struggle to pull new work into development.  When they do eventually pull that work in, it is developed with such poor quality or worse the facade of quality (e.g. formal QA) that it further feeds into the negative feedback loop.

That loop gets even slower to run such that it turns into ‘3 month Stabilization’ phases or an entire quarter whereby the organisation freezes any new releases into production to avoid an outage.

These sort of mitigating steps often occur after some sort of disaster has occurred which has its root cause in poor quality.  One big example is releasing a new version of software such that it shuts down an assembly line at a factory and affects thousands of customers who are prevented from using their mobile devices.  The cost there was millions of dollars.

So asking for quality is easier said than done.  Or does it have to be that hard.  Usually workers are over-burdened.  So limit WiP as was mentioned earlier.  But then ask for quality.  Now that they are not over burdened they can put their efforts into producing quality output.

Give teams the space to improve and they usually will.  Sometimes as a coach I can give them some training and they will do it all by themselves (this interview demonstrates this) to a point, and sometimes being involved with them is needed from the outset or when levelling out or stalling out occurs.

In my experience, results can happen very quickly.  For an organisation I was recently involved with it took three months to go from a cycle time per feature of 40 days to 3 days.  This involved addressing quality and bringing in aligning practices from extreme programming and specification by example.  Reducing WiP and batch size also assisted.  This happened in stages, guided by data from a Cumulative Flow Diagram that mapped the stages of delivery and guided improvement efforts.  The first stage got it down to 9 days (by applying WiP limits, Policies on size and changing the Test Strategy) and then, the next stage, amplifying the unit testing practices to remove an archaic and slow UI testing bottleneck (sunk cost fallacy associated with that) really accelerated the flow of work.

AgWorld, the published case study, did it in 6 months.  They did chose to do for themselves which is fine.  They can achieve a lot more with a coach who can bring the practices quicker and help avoid stagnation which does tend to happen as well.

Find a slow process, you more often than not find poor quality.  Address quality and just observe how things get better for everyone.

 

Advertisements

Keeping up Technical Chops

Got asked to do this for a Coaching job.  It was nice to do.

There is an important and underestimated place for technical excellence.  Heck, it’s a principle!  Combine it with the others 🙂  Standing on the shoulders, Thanks Beck, Rainsberger, Meszaros,  Fowler, Wake, Prag Programmers and  many more unnamed.  It has 36 commits to demonstrate the process.  Feel free to take a look at it.  #agile #tdd #quality #emergent

https://github.com/nzdojo/spellchecker

Read the notes:

https://github.com/nzdojo/spellchecker/wiki/Notes-on-Implementation

‘Keep hands on, that includes the code!’

 


A quote on Test Driven Development from 2003 – Sometimes you need to fail

Wow – I was searching my email for something else and in passing re-discovered this except from an email I wrote in 2003.  I still struggle with this in 2014. Here it is as is with small grammatical errors included:

“I did this last week with someone on my team at InfoHealth.  This person had not unit tested the code (properly) and there were loads of errors.  I fixed them by first writing the tests to catch the bugs and then methodically fixing them.  I finally got to a green light. Yay.

A couple of days later this person changed something and whammo the website we were working on was giving the wrong results.  This person was really having a rough time of it trying to find out what the problem was.  I offered to setup the test harness on his machine but it didn’t eventuate (he had tried himself and was unsuccessful getting it to compile).  The next two days he was away.  I logged on to his machine and got the test harnesses to run and show the first error.  I didn’t proceed to fix them though.

He then came back in.  None of the bugs had been fixed yet after a day of some fruitless bug fixing previously. I suggested him to fix the bugs through the test harness.  He ran the harness and discovered the first error and fixed it, and then the next and then the next.  After about 90 minutes and fixing 9 or 10 bugs he was done.  He comment afterwards was ‘Testing was never so much fun’

Hopefully I gained a convert to Test-Driven development.  Only after demonstrating a regression test suite it made all the difference.  This person was not on the project where we had previously done Test Driven development and I felt he was a somewhat cynical person as well who gently needed to be shown the light.

And so ends my anecdote.”

Testing is so important but we are still refining the practice.  Lately James Coplien and David Heinemeier Hansson (DHH) have been wanting to scale back unit testing (both from different angles), removing some of the pedantic nature (my words).  DHH wants to take it out a level to the integration.  They both have valid arguments.  See DHH’s article for more and this will have links to James Coplien’s ideas as well.  On May 9 2014 Kent Beck, Martin Fowler and DHH will be discussing TDD in a google hangout entitled Is TDD Dead.  It should be interesting and I’ll be tuning in.

Testing exists somewhere and we are trying to get to the sweet spot, balancing the risk mitigating advantages and the ROI on creating and maintaining them.

Edit: The second episode of the TDD occurred last Friday 16 May 2014.  DHH struggled a little with his argument the TDD creates bad design. Perhaps more like inexperienced programmers create poor designs. James Shore weighs in here.

The HeartBleed bug and GOTO Fail bug in Apple products could have been prevented by a unit testing culture and saved a lot of time and money as a result.  This article from Mike Bland explains.  I’m of the same mindset that we should not resign ourselves to an acceptance of complexity and that these things ‘just happen’.  Simple design and unit testing would have greatly mitigated these issues.

The non-unit testing culture means there are probably many other bugs waiting to be discovered.  The relatively small impost on time to do unit testing and do it well is paid back many times over.

The twitter hashtag #IsTDDDead is covering the debate, although now seems to be simmering down.

Uncle Bob Martin puts TDD in the context of Teams, paraphrasing – Good personal hygiene is good for the team.