Programming is Debugging, So Debug Better

Debugging: The schedule destroyer, the confidence sapper, the mire in which thousands of working hours are lost every day. It's time to stop staring at those four lines of code, desperately willing the bug to appear. This session is about the philosophies that will steer you around bugs, strategies for dealing with them, and tools that can shorten a four-hour debugging session to five minutes.

Transcript

1. Programming is Debugging, so Debug Better Yoz Grahame, yoz@yoz.com, @yoz Neo Innovation, Inc.
2. I’VE DEBUGGED SOFTWARE FOR THESE PEOPLE
3. WHAT THIS TALK WILL DO FOR YOUR CODE
4. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program – each 420,000 lines long – had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. –– Charles Fishman, “They Write the Right Stuff”, Fast Company Magazine, December 1996
5. “Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.”
6. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program – each 420,000 lines long – had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. –– Charles Fishman, “They Write the Right Stuff”, Fast Company Magazine, December 1996 known
7. Programming is the art of algorithm design and the craft of debugging errant code. In the words of the great John Backus, inventor of the Fortran programming language: “You need the willingness to fail all the time. You have to generate many ideas and then you have to work very hard only to discover that they don’t work. And you keep doing that over and over until you find one that does work.” –– Ellen Ullman, “How to Be a ‘Woman Programmer’”, The New York Times, May 18 2013
8. Don’t panic. We’ll make it easier than that.
9. ELLEN ULLMAN’S “THE BUG” A RATHER GOOD NOVEL ABOUT SOFTWARE QUALITY ASSURANCE
10. Momentum, willpower and time are valuable. Bugs eat them.
11. Software engineering is hard because bugs.
12. In this talk, you’ll get Bug-Killing Tactics Bug Prevention Strategies Useful Tools Pony Thief Alerts
13. which mostly consist of A Whole Load Of Seemingly-Obvious Tips Which All Beginners Would Be Much Better Off Knowing Yet Even Experienced Engineers Usually Miss
15. 0 25 50 75 100 2010 2011 2012 2013 2014 (projected) Amount of cake and ponies in my life Amount of debugging in my life
16. = =
17. Pony Thieves: Bad or unhelpful compilers, debuggers, libraries, editors and other tools
18. #1: Read The Error.
19. #1: Read The Error. (No, actually read the error.)
20. Errors usually have: A line number An error type A subject A failing operation Additional context A hint for fixing (if you’re lucky)
21. Errors usually have: A line number An error type A subject A failing operation Additional context A hint for fixing (if you’re lucky) Engineers usually ignore at least one of these.
22. WARNING: Errors may change during debugging.
23. Test runners don’t tell you when errors have changed This is a pony-positive opportunity!
24. Turn on syntax checking!
25. Fast iterations maintain momentum.
26. Perl gets it right!
27. Compiler errors & warnings are your friends.
28. Compiler errors & warnings are your friends. (This is why some people prefer strongly-typed languages)
29. How to get it really wrong
30. #2: Check the stack trace
31. “If you’re not getting a stack trace, print one that you can look through...” Jose Valim, creator of the Elixir language and Devise authentication framework http://www.flickr.com/photos/levycarneiro/4016052036/
32. “... and if you’re a Java developer, print the stack trace out on paper and take it home to read.”
33. #3: it! Spolsky & Atwood gave us Stack Overflow for a reason!
34. Perfect for those situations where you have an unusual error and a particular framework (or combination)
35. Is it a library/framework bug?
36. Immature dependencies may cause more problems than they solve.
37. #4: Get it out of your head ... via your mouth.
38. YOU’RE NEVER ALONE WITH A RUBBER DUCK http://blog.codecentric.de/en/2009/08/schmelzende-eisberge-teufelsenten-and-epics-%E2%80%93-agile-2009-tag-2-2/
39. “Visualising the code with diagrams usually helps me think through a problem.” Valerie Aurora, leader of The Ada Initiative, Linux filesystem hacker
40. #5: Create a repro test. (“Repro” means “reproduces the bug”)
41. Tests are great because Super-fast iteration! Automated setup & teardown Green/red is a definite yes/no Prevent regressions Remove the daunt & bugs from refactoring Great for metrics & analysis
42. Automated code processes can find and prevent many bugs before they appear.
43. Prevent bugs with automated analysis Linters check your code for common style problems. Coverage checkers show you how much of your code is being tested by your tests. Complexity analysis tools highlight code which is hard to test and may hide bugs. ... plus loads of language/framework-specific analysis tools!
44. Tests & analysis automated quickly and cheaply: Run tests automatically with a Continuous Integration service: Travis-CI, CircleCI, Solana Static code analysis: CodeClimate for Ruby, many open source tools for all languages Run web app tests across different browsers: Selenium, Sauce Labs, Browserling
45. “I use tests in combination with the Divide-and-Conquer approach.” Jim Weirich, creator of Rake and other fine Ruby tools http://www.flickr.com/photos/fraserspeirs/4473763733/
46. #6: Divide and Conquer. Isolate the bad behaviour.
47. Remember this?
48. How Jim and Shreyas fixed it: Isolate by making the test as small as possible Further isolate by splitting up the method being tested It’s caused by data? Split up the data!
49. How Jim and Shreyas fixed it: Isolate by making the test as small as possible Further isolate by splitting up the method being tested It’s caused by data? Split up the data! It turned out to be an error from Chrome’s JSON parser. Over a day’s ponies stolen!
50. Chrome DevTools Course http://discover-devtools.codeschool.com/
51. #7: Validate your assumptions.
52. #7: Valid- ate your assump- tions!
53. Stress. Confusion. Disappointment. Anger. Don’t let it stop you thinking.
54. We’re here because some of your beliefs are wrong.
55. “You have to treat it like empirical science: go through your assumptions and try to disprove each one.” Lisa Dusseault, ex-Apps Area Director for IETF; also Xythos, OSAF, Linden Lab
56. What’s actually going on in your code? Find out with a debugger!
57. IT’S A DEBUGGER! AND QUITE A GOOD ONE TOO
58. So much better than print statements
59. I asked these top Ruby coders... Jim Weirich Jose Valim Steve Klabnik Aaron Patterson ... what’s your #1 debugging tool?
60. and they said... puts puts puts puts ... and I called them something rude in Yiddish.
61. “I can never remember the commands for the Ruby debugger.” Jim Weirich, who has given talks about the Ruby debugger http://www.flickr.com/photos/fraserspeirs/4473763733/
62. print sucks Awkward to insert Dumb and non-queryable Hard to spot in output Easy to commit by accident Remind me which decade we’re in?
63. Command-line debuggers aren’t great Obscure commands Bad visual structure Slow and unwieldy
64. Having said that... http://www.alanmacdougall.com/blog/2012/06/08/interactive-debugging-with-pry/
65. Instant command lines Ruby: Pry PHP: PsySH Javascript: debugger; Python: code.interact(local=locals())
66. Web framework debuggers Ruby: better_errors Python: Werkzeug, django-debug-toolbar Perl: Plack::Middleware::Debug (?)
67. ... but the point is: Traditional debuggers have problems Too slow to invoke and get to the relevant code Step in/out/up/down dance is horrid ... and often goes wrong
68. The worst kind of print if x.count > 3 print “Got here!” x.doStuff()
69. It’s time to think bigger http://vimeo.com/36579366
70. It’s time to think better http://worrydream.com/#!/LearnableProgramming
71. Panorama Demo
72. Panorama It’s barely a proof of concept, let alone alpha It almost certainly won’t work out of the box It still needs proper packaging & tests If you’re still reading, I’d love some help https://github.com/yozlet/panorama
73. Time’s up, but there’s so much more! Security holes Resource leaks ConcBururencgy s Performance problems Text Ệncøding Time & Date Database consistency OS-level problems Failures in production Network debugging Hardware flaws Everything else
74. Other great OSBridge talks Debugging Without Borders - Chris McCraw http://opensourcebridge.org/sessions/1004 PHP for Pirates: Pillaging interactive debugging from Ruby & Javascript - Justin “bobthecow” Hileman http://opensourcebridge.org/sessions/952 What is That Process Doing? - Greg Price http://opensourcebridge.org/sessions/1069
75. This is the way the world ends: Not with a bang, but a bug.
76. This is the way the world ends: Not with a bang, but a bug. Don’t let it be yours.
77. Thank you! Yoz Grahame neo - http://neo.com/ yoz@yoz.com @yoz on the Twits