SP makes some poignant comparisons between software engineering and reverse engineering (RE) and the problems facing the latter. To summarize: the lack of standardization contributes to the situation that for RE you do not have a clearly defined path of steps to obtaining the goal as you would in software engineering. And where steps are defined often the leap from step n to n+1 is so vast that it leaves to many options in between. Hence RE looks like magic.
I would add to the list of contrasts the fact that sessions for RE typically last very long, even days at times, without breaks. Because there are too many options for going about analyzing the target, and because the distance from step n to n+1 is so large: A) you cannot efficiently stop a RE session without waiting until you reach step n+1 and B) documenting where you are so that you can pick back up later requires documenting all possible steps from the current position and their current priorities. This is like rewriting the design specifications for a software engineering project every time you leave the office. So there is a greater incentive to not stop the RE session until you are dead tired or absolutely have to.
This issue of long start and stop times for RE is slightly reduced by working with someone else (pair RE as SP put it). This is one of the greatest benefits I've experienced with pair RE.
