Start with testing ... create a development environment that replicates Production and start playing with it. Figure out the use cases and trace them to how they mimic themselves in the database and start designing tests for the use cases that you do understand. Try to find any documented requirements and map those against the use cases. Find a tool that can do refactoring so that major variables like "ip" can be renamed to something that makes sense to you. Add documentation as you figure stuff out. I know it's a pain, but try to have fun with it, instead of being annoyed as to how bad it is. It's not going to get better if you hate it. Think of how to express the experience on your resume; I fixed a computer system with no documentation, tiny variable names, and blah blah blah; and helped the company secure 3x more customers. That will resinate with a lot of hiring managers that you succeeded in an area where most fail.

It's beyond totally gross for implementation of anything; especially if you have an object-oriented C# background; such as myself. My version was Visual Basic (shudders). However, I have used MS Access, implemented solutions and it does have some benefits. If you want to use it for a real-time production system; Access isn't a solution for that. It's best to think of access as a database system for a small number of users; Excel with a better programming/forms interface. I've used it in a corporate setting for some simple multi-team workflow processes to be managed, as part of a development effort. Why not write a Windows form application, etc.? It boiled down to corporate standards; the cost/time to provision a server with all of it's security policy overhead was simply unjustified. Access, at least in that space, was ubiquitous which means anybody could install/run it, and it was there to fit a need, when filling out email forms was error prone and led to a lot of misunderstandings.

When I first heard about TDD I couldn't figure out how it was different than what I was doing already ... write a bit, test, write a bit more, test. TDD allow me to formalize what I was already doing by making it easier to write the unit tests I had to write anyway, and these represented a way of passing the torch on to the next person who had to maintain what I wrote, because it documents your assumptions that another developer can easily read. Proof of TDD came on a project where I had to write a complicated calculation engine consisting of perhaps 15,000 lines of code and tens of thousands of inputs. The system was delivered with just two bugs, and both bugs were because of specifications they never told me about. I'm pretty thorough as it is with my software, and have few bugs in general but to know precisely there were only two bugs made me pretty proud. If you are working with others and have to hand off your code, TDD is the way to go. If you have to write unit tests for your code, then TDD is definitely the way to go. Unit test writing after you've written the code is as dull as watching paint dry. But I found that writing tests as you developed didn't feel like writing test cases at all. To know you haven't introduced bugs into your code is also a big benefit. There is a certain kind of pleasure to see all your tests continue to pass green each time you run them too. As to whether you want to learn it or not is really up to you. But if you have to hand off code, or you write code that is very complicated, I think you're foolish not to use TDD. My two cents.