I've heard about those projects people end up on and I'm sure you've heard of them too. Everything is done in the most complicated way known to man never to be understood again.  There are odd debugging like statements with logic in them that might be useful ... strange, undescriptive (cryptic?) variable names to which you have no idea what they might do and don't forget your god classes -- those are a must!  So before we go down this pile of atrocities against the human race, let's look at some examples.  Sadly, these are real world examples.

                If thisRow("FormField").ToString().Trim() = "check12a" Then
                    strValue = strValue
                End If

                If thisRow("ExhibitTest").ToString() <> "" Then bDoExhibit = CType(RetrieveValue(thisRow("ExhibitTest").ToString(), "E", "", docInput, xpathNav), Boolean)

Yes, I have seen the strValue = strValue in the real world.  It's sad and seriously calls into question "WHAT WERE YOU THINKING?".  I can't ask that, those people are long gone.  There's no documentation, the code isn't very readable and to boot -- the database takes a while to save stuff (so checking on saved items might take 2 seconds or 15+).  So as a better developer, what do you do?

1. Ask for some refactoring time for readability.  This won't gain the customer anything except readability.  It will get you familiar with the system and if you've done you're homework (cough unit tests) nothing will change.  Yes, I said it will gain them nothing because to the customer, northing has changed.  This isn't an easy task, at all.  It can take a day or a few weeks depending on how bad it is.  So find a nasty method and start pulling it into multiple methods and make it readable ... this also gives you a place later on to replace stuff and make good recommendations later.

2. Look for ways to make it better, quickly.  Look for quick wins.  If there's simple fixes like text/data related outputs, look for those.  This could also backfire (in my case I made a mistake, it uncovered the worst of the worst and has cost me 24 hours of work) but set a time limit of a 15 to 30 minutes.  This is more to demonstrate that just maybe you know what you're doing.  A pile of little bug fixes will probably look better than one big one ... unless they said they want one fixed first.  It's your job as a developer to let them know it might be better to fix the little ones, just for your own sanity.

3. Be patient.  When dealing with truly terrible, amateur (hobbyist?) written system, frustration will be expected.  Try not to think of the system as someone you want to beat with a coal shovel because they might deserve it and should not have EVER been given a keyboard, much less the OK to develop anything, but think of it as a bad child that needs a little (ok, a LOT) of discipline.  Be that discipline, be that foundation and lead it the enlightened path.  It might take you 3 months plus to get a good feel for a system so don't expect to know it in a week.  Remember, that's why you're there.

4. Take the high road.  You know it sucks, but don't go smashing it with the hulk gloves.  Why?  Someone within earshot might have actually worked on it.  Worse, they could be proud of it.  Worse still, the client personally worked on it ... and is proud of it.  If asked "how bad is it" give them an honest answer, but not surrounded in massive amounts of anger, frustration, etc and blame thyself.  "I don't quite understand how the system is setup and I'm not sure what patterns are used" would be a good answer, whereas "dude, this is the biggest pile of steaming failure I've ever seen, who the f wrote this?" isn't as elegant.