Scaling API-first – The story of a global engineering organization
Debugging 2013- Lars pedersen
1. Quality Up Front
How to spend less time debugging
Lars Jarnbo Pedersen
Co-founder Switch-Gears ApS
2. About me
Partner at Switch-Gears ApS
● Transitioning companies from old
development tools to modern Open Source
ones
Been working for Nokia 2001-2012
● Release manager for S40 software for many
years
● Part of a small team that introduced Git,
Gerrit and Jenkins to S40 development
resulting in BIG productivity gains
3. Pain in SW Development
50%
COST OF BUGS
of developer time is spent
finding and fixing bugs*
*http://www.businessweekly.co.uk/hi-tech/14898-software-bugs-cost-more-than-double-eurozone-bailout
4. Why?
Programming is hard…
● you have to map the problem domain to
the programming language in use
● its usually a collaborative effort
● time pressure
● best practises are not shared
Bugs are discovered late…
● context is lost
● often it is not the programmer who
introduced the bug, who is fixing it
5. Luckily
90%
COST OF BUGS
of the bugs can be
caught during
development*
*http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
6. Because
Average defect detection rate is 25 percent for
unit testing, 35 percent for function testing, and
45 percent for integration testing. [McConnell93]
Furthermore, the average effectiveness of
design and code inspections are 55 and 60
percent. [McConnell93]
8. Peer Code Review
● Beneficial for “quality of review” if the author
pre-reviews and leaves comments for
subsequent reviewers [Cohen2006]
● The longer a reviewer spends on the initial
read-through, the more defects will ultimately
be found [Uwano2006]
● Defect detection drops dramatically after ~60
minutes, to zero after ~90 minutes [Dunsmore2000]
9. Peer Code Review
● Long methods and loops are very time
consuming to understand [Uwano2006]
● Review 100 to 300 LOC at a time, in 30-60
minutes chunks, with a break between each
sitting [Cohen2006]
● Spend at least 5 minutes reviewing a single
line of code [Cohen2006]
● Limit reviewing to 1 hour per day [Ganssle2009]
11. Increase Platform Knowledge
Write Readable Code!!!
● You spend much more time reading code than
writing it - so make it nice to read!
● Refactor if necessary
● Include test-code
Commit changes in logical units
● Always commit working code
● Never mix error-fixes and feature implementations
Write descriptive commit messages
● Make sure the reason for the change is clearly
explained
12. Optimize Development Process
Make it simple on the developers,
● allow multiple workflows at the developers
desk
● don’t let the release/integration process
stop the development flow
● minimize manual process steps
while keeping a strict process
● automatically build and test all commits
● require code-review of all commits
13. This is NOT rocket science!
So why don’t we do it already?
● Waterfall development
● Code Reviews are perceived expensive
● Last generation of tools do not support
this easily
What is enabling it now?
● Agile development
● New breed of Open Source tools
15. Git (DVCS) changes everything!
Git is NOT subversion++
● all operations except for push/pull are
local => well suited for continuous
integration
● allows for multiple workflows
○ development
○ integration / releasing
● is a first class citizen during development
AND debugging!
○ gitk for code analysis
○ git bisect for debugging
21. References
Books
●
●
Code Complete: A Practical Handbook of Software Construction, Second
Edition by Steve McConnell (Jun 16, 2004)
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C.
Martin (Aug 11, 2008)
Articles
●
●
●
●
●
SCM Ranking (Switch-Gears)
CI Ranking (Switch-Gears)
Best Kept Secrets of Peer Code Review (Smartbear)
The Cost of Software Bugs (Business Weekly)
Code Review - Just Do It (Coding Horror)
Videos
●
●
Linus Torvalds on Git (Google TechTalk)
Development at the Speed and Scale of Google (InfoQ)