Programming is Debugging, So Debug Better

Slide 1

Slide 1 text

Programming is Debugging, so Debug Better Yoz Grahame, yoz@yoz.com, @yoz Neo Innovation, Inc.

Slide 2

Slide 2 text

I’VE DEBUGGED SOFTWARE FOR THESE PEOPLE

Slide 3

Slide 3 text

WHAT THIS TALK WILL DO FOR YOUR CODE

Slide 4

Slide 4 text

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 Stuﬀ”, Fast Company Magazine, December 1996

Slide 5

Slide 5 text

“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 ﬁll 30 volumes and run 40,000 pages.”

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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 ﬁnd one that does work.” –– Ellen Ullman, “How to Be a ‘Woman Programmer’”, The New York Times, May 18 2013

Slide 8

Slide 8 text

Don’t panic. We’ll make it easier than that.

Slide 9

Slide 9 text

ELLEN ULLMAN’S “THE BUG” A RATHER GOOD NOVEL ABOUT SOFTWARE QUALITY ASSURANCE

Slide 10

Slide 10 text

Momentum, willpower and time are valuable. Bugs eat them.

Slide 11

Slide 11 text

Software engineering is hard because bugs.

Slide 12

Slide 12 text

In this talk, you’ll get Bug-Killing Tactics Bug Prevention Strategies Useful Tools Pony Thief Alerts

Slide 13

Slide 13 text

which mostly consist of A Whole Load Of Seemingly-Obvious Tips Which All Beginners Would Be Much Better Oﬀ Knowing Yet Even Experienced Engineers Usually Miss

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

= =

Slide 17

Slide 17 text

Pony Thieves: Bad or unhelpful compilers, debuggers, libraries, editors and other tools

Slide 18

Slide 18 text

#1: Read The Error.

Slide 19

Slide 19 text

#1: Read The Error. (No, actually read the error.)

Slide 20

Slide 20 text

Errors usually have: A line number An error type A subject A failing operation Additional context A hint for ﬁxing (if you’re lucky)

Slide 21

Slide 21 text

Errors usually have: A line number An error type A subject A failing operation Additional context A hint for ﬁxing (if you’re lucky) Engineers usually ignore at least one of these.

Slide 22

Slide 22 text

WARNING: Errors may change during debugging.

Slide 23

Slide 23 text

Test runners don’t tell you when errors have changed This is a pony-positive opportunity!

Slide 24

Slide 24 text

Turn on syntax checking!

Slide 25

Slide 25 text

Fast iterations maintain momentum.

Slide 26

Slide 26 text

Perl gets it right!

Slide 27

Slide 27 text

Compiler errors & warnings are your friends.

Slide 28

Slide 28 text

Compiler errors & warnings are your friends. (This is why some people prefer strongly-typed languages)

Slide 29

Slide 29 text

How to get it really wrong

Slide 30

Slide 30 text

#2: Check the stack trace

Slide 31

Slide 31 text

“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.ﬂickr.com/photos/levycarneiro/4016052036/

Slide 32

Slide 32 text

“... and if you’re a Java developer, print the stack trace out on paper and take it home to read.”

Slide 33

Slide 33 text

#3: it! Spolsky & Atwood gave us Stack Overﬂow for a reason!

Slide 34

Slide 34 text

Perfect for those situations where you have an unusual error and a particular framework (or combination)

Slide 35

Slide 35 text

Is it a library/framework bug?

Slide 36

Slide 36 text

Immature dependencies may cause more problems than they solve.

Slide 37

Slide 37 text

#4: Get it out of your head ... via your mouth.

Slide 38

Slide 38 text

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/

Slide 39

Slide 39 text

“Visualising the code with diagrams usually helps me think through a problem.” Valerie Aurora, leader of The Ada Initiative, Linux ﬁlesystem hacker

Slide 40

Slide 40 text

#5: Create a repro test. (“Repro” means “reproduces the bug”)

Slide 41

Slide 41 text

Tests are great because Super-fast iteration! Automated setup & teardown Green/red is a deﬁnite yes/no Prevent regressions Remove the daunt & bugs from refactoring Great for metrics & analysis

Slide 42

Slide 42 text

Automated code processes can ﬁnd and prevent many bugs before they appear.

Slide 43

Slide 43 text

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-speciﬁc analysis tools!

Slide 44

Slide 44 text

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 diﬀerent browsers: Selenium, Sauce Labs, Browserling

Slide 45

Slide 45 text

“I use tests in combination with the Divide-and-Conquer approach.” Jim Weirich, creator of Rake and other ﬁne Ruby tools http://www.ﬂickr.com/photos/fraserspeirs/4473763733/

Slide 46

Slide 46 text

#6: Divide and Conquer. Isolate the bad behaviour.

Slide 47

Slide 47 text

Remember this?

Slide 48

Slide 48 text

How Jim and Shreyas ﬁxed 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!

Slide 49

Slide 49 text

How Jim and Shreyas ﬁxed 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!

Slide 50

Slide 50 text

Chrome DevTools Course http://discover-devtools.codeschool.com/

Slide 51

Slide 51 text

#7: Validate your assumptions.

Slide 52

Slide 52 text

#7: Valid- ate your assumptions!

Slide 53

Slide 53 text

Stress. Confusion. Disappointment. Anger. Don’t let it stop you thinking.

Slide 54

Slide 54 text

We’re here because some of your beliefs are wrong.

Slide 55

Slide 55 text

“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

Slide 56

Slide 56 text

What’s actually going on in your code? Find out with a debugger!

Slide 57

Slide 57 text

IT’S A DEBUGGER! AND QUITE A GOOD ONE TOO

Slide 58

Slide 58 text

So much better than print statements

Slide 59

Slide 59 text

I asked these top Ruby coders... Jim Weirich Jose Valim Steve Klabnik Aaron Patterson ... what’s your #1 debugging tool?

Slide 60

Slide 60 text

and they said... puts puts puts puts ... and I called them something rude in Yiddish.

Slide 61

Slide 61 text

“I can never remember the commands for the Ruby debugger.” Jim Weirich, who has given talks about the Ruby debugger http://www.ﬂickr.com/photos/fraserspeirs/4473763733/

Slide 62

Slide 62 text

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?

Slide 63

Slide 63 text

Command-line debuggers aren’t great Obscure commands Bad visual structure Slow and unwieldy

Slide 64

Slide 64 text

Having said that... http://www.alanmacdougall.com/blog/2012/06/08/interactive-debugging-with-pry/

Slide 65

Slide 65 text

Instant command lines Ruby: Pry PHP: PsySH Javascript: debugger; Python: code.interact(local=locals())

Slide 66

Slide 66 text

Web framework debuggers Ruby: better_errors Python: Werkzeug, django-debug-toolbar Perl: Plack::Middleware::Debug (?)

Slide 67

Slide 67 text

... 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

Slide 68

Slide 68 text

The worst kind of print if x.count > 3 print “Got here!” x.doStuff()

Slide 69

Slide 69 text

It’s time to think bigger http://vimeo.com/36579366

Slide 70

Slide 70 text

It’s time to think better http://worrydream.com/#!/LearnableProgramming

Slide 71

Slide 71 text

Panorama Demo

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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 ﬂaws Everything else

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

This is the way the world ends: Not with a bang, but a bug.

Slide 76

Slide 76 text

This is the way the world ends: Not with a bang, but a bug. Don’t let it be yours.

Slide 77

Slide 77 text

Thank you! Yoz Grahame neo - http://neo.com/ yoz@yoz.com @yoz on the Twits