When approaching reverse-engineering, we have to partition the big puddle of code into some useful pieces that we can manage intellectually, and will likely become parts of the resulting application. In some cases, this is either impossible or valueless. It may be that the application is so hopelessly bad that …

When I was a kid, reverse engineering a legacy application was a challenge. Tools were non-existent, and even a civilized practice like unit testing didn't really exist. Now that we have test driven development, I think we can apply this to reverse engineering the billions of lines of legacy software …

This is not a Python to the rescue story. This is a true, deeply horrible situation. I was rescued by a reframing technique I'll call Extraction.

First, the function had nested if's without enough else's -- the kind of thing that handles two of the four possible conditions.

if( a ) {
    if …

It's about 10,000 lines of C. Much of the C is focused on "framework" issues -- logging, synchronization, parsing the parameters and that kind of thing. In this case, it appears to be 30-50% of the original C code is stuff that is available in Java and can be removed …