Working Effectively w/ Legacy Code? Nope!

For the past 2+ years I have worked for two different national IT consulting companies (first one was bought by the second earlier this year). During that time I have been contracted to work for three different clients (1.5 years, 7 months, and almost 2 months). While there are some things I dislike about this arrangement (e.g. disconnect with other consultants and office staff of my company) there are many things I very much enjoy (e.g. wide ranges of experiences and relationships). Each client has presented its own unique set of challenges.

What is my current challenge you may ask. Legacy code.

My current gig is as the primary (only) developer assigned to support and add features to an existing enterprise web application. This application is somewhere between 6 and 8 years old. I wouldn't say the code is "legacy" just b/c of 6 years; that might be ancient to some and a new born to others. I say its legacy b/c it is 6+ years old code that has been modified by countless people over that time period with no single person staying with the application more than a year or so. To make matters worse, the business use of the application warrants new code being added each year to support that years work while maintaining previous year's code as is. All of this is done without any sort of formal programmer level testing (be it unit or other). All testing is done ad-hoc by the developer of the time, and at the functional level by a seperate business tester. The client pushes TDD for all new projects (even pays for its contractors to take classes on it) but since my app is old, it goes without.

The result? A tangled mess of code that doesn't have a single understandable design (instead it has about 10 different partially implemented designs) and which is extremely fragile.

To make things even more interesting, my current assignment has me working in a different arrangement than I had at either of my past clients. Currently I work under a skilled tech lead who handles efforts around several applications. He is very sharp, but hasn't been supporting this application long enough to know all of its ins and outs (if anyone ever could). My current role (and newness to the project) has all of my work being reviewed by the tech lead.

I believe myself to be a capable developer, but my recent track record doesn't support it. The combination of a poorly designed and implemented code base, my newness to the application, a very fast release cycle, and numerous code reviews has led to several mistakes on my part. Luckily the tech lead understands this and hasn't put much blame on me ... but if you know me, then you know I don't like it when I can't do something and even less when I know I can, but didn't.

I want to fix this problem, but am not sure how. I have borrowed copies of Working Effectively with Legacy Code as well as Test Driven Development : by example. These are in addition to my slow reading of Refactoring by Martin Fowler and JUnit Recipes. These last two were given to me via the TDD class I took a few weeks ago. Hopefully, reading up on better technique for making changes without changing existing behavioir, how to add tests to existing code and how to make design changes without breaking stuff will help get me back on track. I hope.

Anyone else have any similar experiences? What did you or your team to do minimize the risks?