Not necessarily true by the way.

This is what I do in my day job btw and I happen to work in the financial
industry too. My starting point? I throw automated tools at it to get a
sense of what I am dealing with - ugly code, good code gone bad, script
kiddies turned programmers, hot shots who only care about their way etc.
Tools like FxCop, Devpartner are a staple and good enough to give you a
general idea.

Next, I start with the code, line by line. If it's too big or I get
discouraged, I target the important parts and code review those for
performance issues. I have a list of issues that I look for in the code -
common errors like leaky connections, performance intensive code that can be
refactored, for loops and variable declarations inside loops, poorly
structured logic, COM interop issues, XML manipulation etc. Automated tools
can't really get after those issues, the eye and experience is what will get
you there. If there's a particular routine that is slow, maybe I will throw
Devpartner performance analyzer at it, maybe I'll take a look at the raw
code, it depends on how I'm feeling about the code. I prefer to trust my eye
against the code but that requires a lot of effort and time that I don't
particularly have.

If I grow suspicious at what I am looking at, I'll stop, step back and do a
design review before continuing. Sometimes I start with a design review but
these applications are typically built in concert with architects so I
believe they are well intentioned to begin with. It falls apart when time
constraints and lack of coding best practices mix in to the pot. From that
point, I know enough to make a judgment call - this thing sucks, scrap it
and start fresh or it's good it just needs some adjustments. Or, it's wrong
from the design so everything else is a band-aid. When you make that call,
know enough about best practices and proper coding to stand by your
decision. You get better the more you do it.

The other ideas make sense also, but depending on the complexity of the
application business requirements, it may be easier to rewrite. I know this
sounds crazy to some people, but the current application requirements are
probably now know; as when it was written it was not, this usually is one
reason for the bad code/performance.

So in general; "knowing what we know now, how would we build the
application, and how long would it take?"

Sometimes it easier to rebuild, than spend a lot of time finding and fixing
the problems. The new code is usually of better quality and easier to
maintain also.

I have been working in the finance industry for a long time also, and have
taken this path a few times...

Schneider