When people discuss the creation of software, they make a clean separation between the tools that one can use, such as an IDE, and the techniques one can use, such as Object-Oriented Programming. In general, good tools can offer efficiencies, analysis, or insight that would be missed without it, and they might even help to reinforce the use of certain techniques, such as Eclipse's support for refactoring as a core piece of functionality.

For whatever reason, people have trouble making this same distinction with debugging. When people talk about it, they tend to refer to the tools they use for the job rather than their theoretical approach to problem solving. Case in point: a post about debugging on the Meebo Blog. It didn't contain any misinformation, but it only mentioned the tools that they use: gdb, core dumps, strace, etc.? It left me wondering: so you open up the core dump with gdb, then what?? How do you search through the massive dump to find the information you need?? Do you keep a detailed history of common errors? Do you generally have an idea of what is wrong before you start?

The notion that the availability or knowledge of certain tools shapes or empowers your thinking has been called "The Fingertip Effect" by Dr. David Perkins,? referring to the concept of? having resources "at your fingertips".? He used it to formulate an argument in the context of educational technologies, where the fingertip effect is generally taken as a given.? Parents frequently demand that a certain number of computers, laptops, PDAs, technology X? be present in every classroom or within the school in order to maximize student opportunities.? The implicit premise is that by making these resources available "at students' fingertips" they will suddenly be able to use them in an appropriate way, and they will naturally benefit.

Most research seems to suggest that this is not true (and Dr. Perkins coined the term for the purposes of investigating, and eventually discrediting the idea).? The problem is that students widely vary in their ability to make use of new technologies without corresponding instruction in its affordances (now I'm really pouring on the ed jargon).? So the fingertip effect isn't necessarily wrong, it's just not a good educational strategy;? technology has to be combined with an effective instructional program so that students actually understand what it can do for them, how it does it, and why.

The same can be said for debugging.? It isn't that a focus on tools such as gdb, strace, or even Delta Debugging is wrong, it's that if you don't have a framework for understanding how to isolate and fix bugs, tools won't help you.? In the same way, having Microsoft Word will not make a poor writer into a good one, even though it will allow a good writer the opportunity to become better since they can spend less time on copyediting and more time on style and content.? In retrospect, the idea that tools cannot be substituted for techniques seems obvious, yet parents continue to call for more computers without calling for more computer-savvy instructors, and the debugging field continues to offer a wider variety of tools without regard for instructing people in their use. My hope is that the material on this blog helps people make better use of the tools that are already at their fingertips.

From Engadget yesterday:

Merely three days after hearing of one user's run-in with Apple over his unlocked iPhone, the company has released an official statement warning users that "unauthorized iPhone unlocking programs" could cause "irreparable damage to the iPhone's software." Furthermore, the firm stated that these apps could result in the handset becoming "permanently inoperable when a future Apple-supplied iPhone software update is installed" -- you know, like the one coming "later this week" that includes the iTunes WiFi Music Store.

The team that developed the unlocking software offered a response today:

Based on download numbers, the iPhone Dev Team believes that, worldwide, several hundred thousand people have unlocked their iPhones. That number continues growing every day. The removal of the lock, a bug, was a major step forward in the iPhone development. It made the iPhone free and useful to anyone, not only to those in certain countries.

Apple now announces that the next firmware update, expected later this week, will possibly break the handset of all of us free users in the World. It speaks of "damage" done to the firmware and "unauthorized access" to our own property, The removal of those firmware problems, which were built in in favor for AT&T, does not cause "damage" as they want to make us believe.

We will provide you with a tool in the next week which will be able to recover your nck counter and seczones and even enables you to restore your phone to a Factory-like state.

Apple has taken a lot of flack for this statement, with people arguing that they are fearmongering with their claim that the unlock will break their phone when the firmware update comes out, and by making such an update in the first place.? My question is, why would Apple go to the trouble of telling people about the problem ahead of time?? Why not just release the update and break all the hacked phones, thereby making people wary of unlocking things at all?

To me, this whole exchange seems like some tricky subtextul communication between Apple and the iPhone hackers to keep customers, who want unlocked iPhones and give apple $, and vendors, who want locked iPhones and give apple $, happy while still allowing everyone to go about their business:

Apple: I'm going to give you until the count of 3 to put your iPhone back the way you found it! I'd hate to have to take away your privileges altogether (wink, wink)!

iPhone Dev Team: Okay, okay, you win.? I'll put the iPhone back the way it was.? You can roll out that upgrade whenever you'd like (wink, wink).

I guess we'll see what happens the next time around...

When called in to fix a computer problem at someone else's location, what should you bring with you to increase the chances of success?? Certainly, it helps to know something about the problem before walking in the door, but having a generic set of tools that will assist in a wide variety of situations is critical. Here is a list of what I put in my toolbox.

Hardware:

• ?Laptop - You need your own computer since there may not be a working one present. Dual boot Linux/Windows, although you can stay in Linux, generally speaking. Better yet, run Linux and have a few virtual machines with different OSes ready to go.
• Wireless (cellular) modem card - This is not necessary, but I like to have a high-speed, dedicated internet connection that keeps me from having to rely on the customer environment, especially if the network is the problem.
• Wireless (802.11x) card - For working with/sniffing wireless networks
• Hub - You can use a switch that has a sniffer port that allows you to see all the traffic, but a 4-port hub makes it easy to insert yourself into the network quickly and unobtrusively
• Ethernet cables - Probably at least two standard and one crossover, just in case.
• Computer screwdrivers - in case you need to open the case and look for evidence of physical problems, or pop out flaky hardware.
• Thumb drive with all the software described below for as many OSes as they are supported on - Since a 2GB thumbdrive costs so little, this is easy, and allows you to quickly copy analysis and dev tools onto other machines.

Software

• Standard network and comunication utilities - ping, traceroute, ssh, etc - helpful for checking the status of machines and for answering questions about networks
• Standard network service daemons - dhcpd, named, etc - helpful for allowing your laptop to pose as various services.
• Advanced network utilities - nmap, wireshark - for really looking at what is coming over the network, and analyzing hosts
• Standard? gcc toolchain - don't leave home without it
• A serious IDE such as Eclipse - I like Eclipse because I can use it to quickly examine Java, Ruby, C++, PHP, etc with all the plugins I've installed over the years.? If you have a Windows partition/VM and some extra cash, Visual Studio can help too.
• Linux rescue CD from your favorite flavor - That way you can boot into an OS where you can do whatever you want, including inspect partition tables, mount various drives to access content without needing passwords, and generally, take the machine's possibly broken configuration out of the equation to separate out hardware and software issues.
• Password crackers and recovery tools - This one can be ethically questionable, but when you need some files that some developer left in their account and they've left the country for a 1 month vacation, a customer will be begging you to break them out.? I recommend something to recover BIOS passwords, a zip password file cracker, and if you want to lug a big drive around, a generic password cracker that uses rainbow tables to break systems protected by weak hash-based encryption.

That's a good starting list.? I may post again if I add other tools that may be of interest, and feel free to add your own suggestions in the comments.