What is Distance Debugging?
Distance Debugging is our unique approach to finding and fixing problems. Many hours are lost to bug fixing by the development team during the creation a project, and despite that time spent, many products still contain serious flaws that cost end users time and money, but which they nonetheless continue to use. The problem isn't that developers and users don't care, but that, until now, they had have no alternative because there was not a specialized service devoted to fixing problems. Most contractors want to come in and build a brand new product to replace the existing system, or swap out existing infrastructure for the latest and greatest because fixing the existing problem seems undesirable or impossible. Distance Software is different because we love the debugging process and want to make everything work as is.

I have IT problems. Why don't I just call GeekSquad(TM) or the like?
If you have a computer with a virus, or you need a piece of software installed, or you just can't seem to get on your home network, please give your preferred troubleshooting service a call.

While we can easily handle those tasks, we want the really, really hard stuff, like:

• Your corporate network goes down once a month, for no apparent reason.
• Your website slows to a crawl on Wednesday afternoons, when almost no one is on the site
• Your database gets unexplained data corruptions when under a heavy load.

Any issue that requires a keen eye for detail and a new approach to problem solving can benefit from our expertise We also offer services to work alongside your existing team, like Fresh Eyes where we provide just that: a fresh look at an existing problem to hopefully get your team kickstarted on some new approaches, and our Debugging 201 and 301 training series to help your team get better at fixing problems without our help. See our Services page for more information.

Why would my team need Debugging Training?

Developers spend an enormous amount of time fixing code, perhaps even two or three times as much as they do writing it, yet debugging as a field has almost no literature devoted to it, few experts, and little research. If you search for debugging on the web, you might find a few articles talking about the scientific method and being systematic in your searching. There are some resources about how to get better at using a particular debugging tool like gdb. There are even some pioneers who are proposing new techniques and tools to help out. However, most developers continue to learn from their previous experience and even if they have a knack for fixing things quickly, they lack a broader framework for organizing their techniques and for communicating those concepts to others. Our Distance Debugging curricula aim to fill in this gap by organizing the best practices together into a larger set of principles, theories, practices, and a vocabulary for talking about debugging. By bringing our curricula into your organization, your team learns these proven techniques to dramatically improve their speed and success rate in debugging even the most complex problems, as well as gaining a framework for organzing their future experiences and for concisely communicating with each other during the debugging process.

Why the name Distance Debugging?
In our experience, most hurdles you encounter in debugging problems stem from problems of distance. Here are the types of distance we encounter, and how we address them:

• Physical Distance - The problem is taking place in another city, state, country, or even somewhere nearby, but we are simply not close enough to observe it directly. We understand how physical distance introduces communication errors in the process, and how to combat that.
• Temporal Distance - The problem happened yesterday or a year ago, and all we have left are some log files and human memories. We combat temporal distance with detailed logging procedures in our own system, and by using computer forensics techniques to recover seemingly lost information.
• Mental Distance - There are always things we don't know, and sometimes are simply unknowable, which have to be accounted for when analyzing the problem. We rely on a broad understanding of computer science and human psychology to make educated guesses when possible, and we know how to do serious research to fill in as many blanks as possible.
• Operational Distance - The problem would be easy to fix, but you don't have permission to change things, or you simply can't get to the person who needs has the authority. We are masters of the workaround, often finding ways to fix the problem without requiring any special permission, and we also know how to navigate tricky corporate hierarchies.

What are some examples of advanced debugging techniques?

Most developers will know how to apply the scientific method to define and test theories of the problem, and hopefully they know how to use the basic features of a debugger. Because we teach more advanced techniques, we call our lowest-level training course Debugging 201, instead of Debugging 101. Here are few examples of what we cover:

• Best practices in logging and error handling to make sure you are getting all the data you need, since it's the errors you don't see that will really slow you down
• Charting your theories on the probability and testability axes to find the most probable and most easily testable theories first
• Using source code management tools to help quickly narrow down your search for a newly introduced bugs
• Developing trusted intermediaries at customer sites who you can rely on for higher quality information when things go wrong
• The art of the workaround: fixing problems on a deadline.

This list should give you a flavor for the difference in our approach to debugging.