Eight Agile Wastes of Hanukah: #3 Defects (and Dreidels)

I joke that Hanukah is the festival in which Jewish children eat fried food and learn to gamble! Hanukah features an iconic spinning top, the dreidel.

Each dreidel has four sides, each with a hebrew letter. Together the letters form an acronym that translates as "a great miracle happened here".

There are rules for a gambling game based on the Dreidel letters, but in my family we just enjoy spinning them in increasingly challenging ways: preferred hand, other-hand, both hands simultaneously, inverted, etc.

Agile Waste #3: Defects

Software defects (colloquially known as "bugs") are instances where the software either malfunctions or behaves in a way inconsistent with its intended behaviour. Famous examples have resulted in lost space-craft, exploding rockets, and death from malfunctioning medical equipment. More down-to-earth defects result in losses of data, financial miscalculation, security breaches. Defects also result in programs that are slow or crash or don't respond to user input.

Designers and Programmers create a lot of defects. The defects that affect end-users and customers are the ones that haven't been prevented or caught and remedied ("debugged"). But unfortunately, in complex software, removing one defect can introduce others.

Finally, software is an automated process, so manual (and mixed automated/manual) processes can be defective too. These too need to be debugged.

What to do

Detecting and fixing defects are important activities, but not intrinsically value-adding, and the rule-of-thumb that prevention is better than cure applies. The longer a defect goes undetected the more expensive its impact and the higher the cost of remediation. The general idea is to move quality left:  it's better to catch defects earlier than later.

Suggestions:

1. Develop less features (see waste #1) as more software leads to more defects!
2. Develop clear specifications via techniques such as Specification by Example / Behaviour Driven Development (BDD)
3. Adopt a modular architecture so that defects can be more easily isolated
4. Rely primarily on lots of automated tests, rather than manual testing
5. Do manual exploratory testing to find subtle defects
6. Write those automated tests at multiple levels (unit tests, component tests, functional tests), to test both technical assumptions and expected behaviour
7. Have programmers peer review each other's code: the fastest feedback loop for this will be in real-time via pair-programming or mob-programming
8. Use test driven design / development (TDD) to improve code quality by writing tests first and "refactoring" code for simplicity and elegance.
9. Run the automated test suite against every change via Continuous Integration (CI)
10. Explore more sophisticated preventative techniques: e.g. Design by Contract (DBC)
11. Generally prioritise defect fixing over new feature development: don't trade away quality