Debugging and Source Code Tools

More from our friends Nate and Natty at Everlater – this time on debugging.

One of the most important techniques we used when learning how to code is debugging.  It allowed us to do two things: fix our own code when it was broken and parse through others’ code to better understand how they were doing things.

From a backend perspective, debugging is essential.  When I first started writing code, I would write what I *thought* was the correct way to do it. Ninty-nine times out of a hundred I was wrong and the code would blow up with some ugly exception that I had no clue about.  Copying and pasting the exception into google got me decent mileage, but the real silver bullet I discovered was just start from the beginning of the method and step through it using the ruby debugger and figure out where I had gone wrong.  Almost always I had forgotten to assign some variable or I was calling a method that did something different than I thought.

The other huge thing that is related is that I read and still read copious amounts of open source code written by other people.  I’m better at understanding it now, but at the beginning I would take a debugger and walk through the code myself to try to figure out exactly how their code was working so I could make my own code better.

This is super important on the front end as well.  Using tools like firebug or web inspector to take apart existing sites and figure out how they’re doing something or making something beautiful is a great way to learn better techniques for front end development.  They’re also essential for figuring out how to fix a layout when it’s broken, or how to figure out why an ajax request didn’t respond the way you would expect.

This is a great, free resource to use when learning how to program and really helped us to bridge the gap from a basic programming book to what current philosophies on development were.  A huge hat tip goes out to Jeffrey Kalmikoff for posting a comment on a previous post in this series that made me remember how important this is.

Somewhat related are tools that help you keep your code/team in order.  By far the most important is a good version control system.  This is something that they don’t ever teach even in college classes, but it’s hugely critical to building a project in the real world.  We use git at Everlater and it’s been an amazing choice.  When coupled with GitHub, it makes working even in a team of two seamless even if you’re working on almost the same code.

Also important is some way of keeping track of the quality of your code as your project grows.  This includes a good issue tracker (we simply use the to-do list feature of the free version of Basecamp), and a good way to know when there’s something wrong in your application (Hoptoad is great for Rails devs.)

  • To: Brad Feld, Subject: Iran And Me (Digital Ninja/Commando)

  • I think this may be the most important post of them all so far. Debugging is the most crucial part to the coding process because, if done successfully, it allows the code to truly shine and operate in the most efficient manner possible.

    How did you guys figure this process out? The beginning stages of coding are fairly easy with all of the resources out there, but debugging is silently considered more of the "secret sauce" than anything else.

    By the way, I've been writing each program and resource down as each new post is released. Can't wait to collaborate with my friend on the project we're about to undertake.

    • I completely agree…I really think that debugging *is* the secret sauce. In a way debugging is a comprehension test for how well you know code — if you can figure out the problem, there's a good chance you have a deep understanding of how the code actually works. It's a process that we've just evolved over time.

  • Hoptoad is great tool and helps monitor the exceptions users are facing if any. Its quick to find issues and their causes.

    One important reason to use debugger for languages like Ruby that do not give you a compile time error is to make sure you are able to go thru each and every line of code in the debugger and are sure code is doing what it is supposed to. Because there might be a typo burried in an if statement that might not be caught when testing but this might blow up later on when that if is hit. I know preparing test cases is important, but I am not sure if someone can hit all the lines of code using different test cases unless they are using a debugger to write the test cases itself.

    I wrote a comparison of Java and RoR last week . This typo issue makes me favor Java somewhat.

  • StartupTrekTV

    What do you guys think of Coda from Panic SW? Do you use BBEdit?

    • Actually we just use textmate or vim to edit and then use the command line ruby debugger.

  • babar

    do you have separate testing and production environments, and how do you handle configuration?

    • yep — everyone in our company has a separate testing environment. Then if we need, we fire up a separate staging server for complex migrations before deploying to production. At first we wrapped our own server configuration using capistrano, but now we use Engine Yard to handle all of our server deployment — it takes a little off our plates, and they are fantastic at doing deployment.

  • Ted Howard

    In my experience, the most important choice in determining ease of development is the basic technology and tool choices.

    As someone else stated, Ruby has no compilation or static analysis check so the vast majority of errors will only be encountered in runtime. This vastly increases the odds of releasing buggy code unless your test cases exercise all possible code paths. Want to optimize a performance bottleneck? Does your profiler show memory allocations and garbage collections along with basic instrumented and sampled function profiling? Does your profiler do comparisons against baseline? Do you have a system with profile-guided optimizations?

    When you choose technology that's easy to use, your development efficiency goes up, your development costs go down, your bug risks post-release often go down, and due to all off that your developers' morale tends to stay higher as they get to release features faster and spend more time on new features than on debugging with piss-poor tools. Your choice obviously impacts other aspects of the business, including hosting costs and talent pool.

    My technology of choice is Visual Studio with either C++ or C#. One weekend recently, I needed a developer morale boost after months of technology frustration (PHP and Ruby both cause me great pain btw). I broke out Visual Studio, downloaded the Windows Phone 7 tools, and rebuilt one of our (Playdom's) more complex games in Silverlight in about 10 hours. I went back to work recharged.

  • thanks for sharing information…

  • yes, debugging is very important on software development process..

  • Debugging is the most frustrating part of writing code. I think it's just too easy to make mistakes so a tool that can show how some code was written could be a big help.

  • Your comment text = I totally agree. Using search today (vs. search ala 1999) as a proxy for the problem is good – I almost included an example of this in the post but then decided it made things to ponderous. Soon we’ll need PEO (personal engine optimization).