The document discusses the 'bugs first' approach in software development, emphasizing the importance of addressing bugs before proceeding with new features to maintain software quality and improve predictability in release planning. It outlines basic rules for debugging and quality assurance, insisting on daily testing and fixing of defects, effective change management, and maintaining high coding standards. The overall message advocates for a proactive stance on bug management to enhance product stability and reduce development time.

1. Bugs first,
even before new Features?
or
Zero Defect
1

2. What is “Bugs first”?
 Alternative one: Fix bugs immediately
 “Fix all bugs before starting next user story.”
 Sprint: “User story can be closed only when all bugs have been fixed.”
 Kanban: “Work in progress (WIP) can only be closed when all bugs have been fixed.”
 Alternative two: Fix bugs in sprint
 “No bugs at end of sprint.”
“No bugs as done-done criteria.”
2Oliver Schreck

3. Potentially shippable product
3Oliver Schreck

4. Why?
 Bug-free, stable software makes a tremendous impression, especially when
you demonstrate intermediate versions.
 Closer to full product quality in each sprint
Higher Product quality
4Oliver Schreck

5. Why?
 Each unsolved bug is a piece of work that need to be done “later”
 Reducing bugs leads to less “later work”
 The need of stabilization sprints after “end of development” decrease
 Velocity measurements become more true
 In sum: Release planning becomes much more reliable!
Higher predictability
5Oliver Schreck

6. Finding Bugs early
6Oliver Schreck

7. Finding Bugs early
7Oliver Schreck

8. Zero Defect
 Maintain the software at highest quality during the development
 Improving quality actually reduces development time
 Programmer writes between eight and twenty lines of code a day;
 the rest of the day is usually spent on debugging
 Studies done at e.g. NASA, IBM, have shown that better QA leads to shorter
schedules.
 An IBM study concluded that software projects that make quality a top
priority typically have the shortest schedules, the highest productivity, and
even the best sales.
8Oliver Schreck

9. 9Oliver Schreck

10. 10Oliver Schreck

11. 11Oliver Schreck

12. 12Oliver Schreck

13. 13Oliver Schreck

14. 14Oliver Schreck

15. 15Oliver Schreck

16. 16Oliver Schreck

17. Ten basic rules – (1-5)
 Test your product every day as you develop it, and fix defects as soon as you find them.
 Gated checkin, 20 minute build, Daily Build
 Once you find a defect, fixing it becomes your number one priority, and you avoid writing any new code until the defect is 100%
eliminated.
 Review your code regularly.
 Code inspections are far more effective than testing
 Code reading detected almost twice as many defects per hour as testing
 Rewrite poor-quality modules.
 Typically you find that 20% of your routines are responsible for 80% of your errors
 Assume full responsibility for every bug.
 95% of all software defects are caused by the programmer. Only 1% of defects are hardware errors, and the remaining 4% are
caused by the compiler, the OS, or other software
 Never dismiss a potential bug; find out the exact cause of any anomaly, especially if irregular
 Handle change effectively.
 Carefully consider how each change will impact your pre-existing code. Poor integration of unanticipated features is a major cause
of defects
17Oliver Schreck

18. Ten basic rules – (6-10)
 Rewrite all prototyping code from scratch.
 Rapidly prototyped features that slip into the final product are a major source of bugs because they are not subject to the same
quality standards as the rest of the code.
 Set QA objectives at the beginning of every project.
 Set QA goals, e.g. performance, quality standards, coding guidelines
 Don't rush debugging work.
 50% of all bug fixes are done incorrectly the first time, often introducing new bugs in the process.
 Take the time to understand the source of the bug.
 Write UT first to verify your correction.
 Treat the quality of your code at the same level of importance as the quality of your product.
 Rate your code on a scale of one to ten for overall quality.
 Are you sure that it is above 8, if not rewrite it.
 Learn from every bug; each one represents a mistake that you made.
 Learn why you made each mistake
 Adopt simple coding conventions to avoid common bugs, e.g. initialize each variable, release memory, try/catch, comment your code
18Oliver Schreck

19. Accumulation of “Undone”
19Oliver Schreck
preparation development
Undone Undone
Undone
Stabilization
Iterations
Planned
Release
Actual
Release
Undone
Unknown amount
of undone work !
(Ken Schwaber)

20. Open Bugs Compared
 Waterfall compared to “Bugs First”
20Oliver Schreck

21. Why? - Faster Learning
 Fast feedback enables fast learning
 Improve coding practices
 Improve system knowledge
 Improve domain knowledge
 Additional bugs can be avoided
21Oliver Schreck

22. Why? - Less total effort
 The earlier a bug is fixed, the less is the administrative cost
 Fix bugs as long as the code is still fresh in mind – is faster
 Fix bugs before the code has developed further – is easier
 A lot of time can be saved in system integration and test – expensive test environments
can be better used
 Each sprint provides a stable platform for the next one
22Oliver Schreck

23. If you see a problem  fix it!
23Oliver Schreck

24. Questions?
If (unclear == true) then askme();
Oliver Schreck