Sometimes, this kind of mistake is just that - a mistake, no getting around it. I would suggest though, that sometimes, this mistake is more the result of lack of lack of planning in the design and assembling of a project, most especially non-trivial ones.
1. Power should be the -last- thing connected, and the first thing disconnected, when working with the project.
2. Free-hand probing with test equipment should not be done, if possible, while a device is under power; if necessary, then extreme care should be taken, and only a single probe used, with the free-hand not holding a probe placed in a pocket or otherwise restrained from wandering near the other probe or the chassis of the project.
3. If test equipment needs to be used, then the project should be powered off, the test equipment attached, then the project re-powered.
4. Before (re-) applying power, all connections which have been changed or added should be triple inspected to verify that no shorts or opens, or other changes, have occurred.
5. A project should begin with a design, ideally a drawn schematic. This schematic (actually, a copy of the original schematic) should be referenced to construct the physical design. Test points should be identified and noted early in the schematic for future probing needs.
6. Using a defined layout and color-coding scheme for power, ground and signal busses, as well as identifying test points, when prototyping on a breadboard, can be extremely helpful (though time consuming); granted, this generally precludes the use of any currently sold "jumper wires", as they tend to be color coded by length.
7. Marking power busses with voltage levels (using a marker or other means) can be helpful as well; this, used in combination with an identifiable color code for voltages (common is black for ground, red for 5 volts, yellow for 12 volts, which is from PC power supplies), can help prevent mistakes.
8. If your breadboards have power busses that can be separated from the board, doing so can also help prevent problems (mount everything on a non-conductive backer-board of wood or plastic, using double-stick tape or other means).
9. As you construct the project from your schematic, mark off the connection on the schematic using a highlighter or felt marker of the same or similar color as your wire color-coding scheme. This does two things: a) it notes you have made the connection, b) you can reference the color to your wiring at a later point to verify that things match as you change them. If changes are made, the color coding should be changed to reflect this (I realize that this would become unwieldy on very large designs).
I'm sure more could be added to the above list; I'm also sure much could be changed or updated to reflect different design realities (and if you have suggestions, please post them). Ultimately, though, reducing the potential for mistakes involves careful planning, meticulous up-front design, and lots of documentation before, during, and after implementation. It is the bane of any electronics project, but also tends to be the marker of successful projects.
This same kind of attention to process and design should be applied to software as well, but it too seems to suffer the same lack of attention, as any experienced veteran of software development can relate (take heed).