How do we suck?

• Bugs are unavoidable in anything but the most trivial of systems
• This belief didn’t always exist, and the fact that we have allowed it to become acceptable is described by the term Normalization of Deviance
• This belief doesn’t exist in the hardware community – anything > 0 defects is a failure
• Agile technical practices can drive defects rates down to 0
• We put up with unrealistic demands and expectations in software development
• We’re told to “Git ‘r Done”, and we just go ahead and do it
• We slack off with respect to discipline in the development process
• There’s a belief that testing slows you down, which is very short-term thinking
• People are not committed to lifetime learning
• People focus on their current pigeon hole until they are forced to change, rather than seeking change
• Perception that they don’t have time to look at new trends and technologies
• We need to differentiate between specification/requirement defects (essentially mistakes in shared understanding) and true technical defects
• At the core, people are not taking responsibility for quality, and they are not aware of the impacts of their action or inaction

So, how do we “un-suck”?

• The suggestion from the crowd during the presentation was “BLOW!” :)
• First, eliminate QA/Product Support/Solution Implementation Teams as separate, downstream functions
• Eliminates externalizing the problem, i.e. “QA will find all the bugs for me.”
• Integrate all functions within the team, and begin testing as soon as the first line of code is available to be tested… or sooner!
• Include the end user or at least their perspective – what’s their experience?
• Broadcast success stories where the goal of 0 or near 0 defects has been achieved
• Perform Root Cause Analysis, i.e. fix the system that allowed the defect to be introduced in the first place
• Create the “Zero Defect Society“
• “No bug left behind!”
• Concept is that we know, and have known for decades, how to prevent defects almost entirely. We now have tools to make it easy. It’s time to take responsibility and do it.
• We need to take a mentoring approach:
• Books and presentations are good, but this is a hands-on issue – developers need to learn how to prevent defects
• We need to begin educating a new generation of developers that 0 defects is not only attainable, but expected
• This needs to start in post-secondary institutions like the U of W and even into high schools

What challenges will we face?

• This is an exercise in changing the behaviour of the software delivery community
• 46 years after the U.S. Surgeon General’s report which showed that smoking was harmful, the rate of smoking has decreased from 42% to just under 20% in the U.S.  The takeaway is that even when people know that a behaviour is harmful, they will continue to do it when the short term effect is perceived as good
• We need to start a campaign to stop developers from creating defects, not unlike smoking cessation campaigns
• Defect creation needs to become socially unacceptable, not just intellectually unacceptable
• This message needs to be pushed at people learning programming in high-schools and post-secondary institutions in order to create a new generation of developers that aren’t biased to believe that defects are expected and acceptable
• To accomplish that, we need to reach out to teacher and professors with the same message
• Presentations, videos, guest lectures, etc.
• There will be significant pushback regarding the cost of attaining 0 defects
• For greenfield work, the argument is simple – it’s an investment that pays off very quickly
• For legacy work, it’s also an investment but with a longer term payoff
• “How do you eat an elephant?” “One bite at a time.”
• You can’t simply stop all work and make the defects go away.
• The cost of defects and even just bad code must be made painfully clear in order to quantify the bad behaviour
• We drew a graph that illustrated how to see technical debt creeping into code
• Over time, the ability to deliver features will erode while the number of defects (or the rate at which they appear) will increase
• Christian Gruber drew a graph that illustrated the point at which the cost delivering “the next feature” meets the cost of rewriting the entire system

In the end, though, the basic message is that we all – programmers, testers, managers, business people – need to take responsibility for our work in order to move past the notion that defects are OK.

Posted via email from Agile Coach Camp Canada 2010