Possible Duplicate:Ive inherited 200K lines of spaghetti code  what now? Not long ago my company placed me in a team that deals with some of the most complex bugs that are in production. The thing is that almost all of these bugs are in legacy applications I am having a really difficult time understanding and debugging, and these are some of the reasons:Bad software designLots of code duplicationMisleading commentsBad names No documentation at allThe creators of the software no longer work in the companyReally big classes and methods, very badly programmedBugs are very badly documented and the operations team makes very poorly documented reports on the issues that occur.It is very time consuming and frustrating. As a TDD and ATDD developer,  I try by starting writing tests to triangulate and pinpoint the problem, but there are so many things that need to be mocked that it is very difficult. Also the business analysts don't provide criteria for this software since they don't even know it themselves. The only thing they say is that it needs to be fixed.I thought that maybe here I could find somebody with experience in legacy software that could give me some advice on how to deal with bugs in an environment like this. I feel I am doing software archeology when working with this. Also it is very stressful and this big amount of frustration makes me feel useless and unproductive since it takes weeks sometimes to fix bugs. I always worked green field development and this is the first time I am doing production support. I would really appreciate some advice.
How to understand and debug legacy software?
java;tdd;debugging;legacy
You have hit the nail on the head - What you have complained about is the definition of Legacy software. Working on this class of software requires a different mindset to Green-fields work. Your stress is a result of you measuring your progress against unrealistic measures. Don't try to put todays ideology on yesterdays work. If it was not designed around TDD and UT, then retro-fitting Test driven methodology is a major, expensive and difficult undertaking. As you are finding - shoehorning todays silver bullets into yesterdays failed silver bullets is far from the ideal way to work. If carefully though through, with clear understanding of goals and benefits, it can be worth while.  However, it quickly devolves into negative returns. Go for the low hanging fruit and develop tests only if it clear they will be used many times and find many defects.The best approach is to remove unrealistic expectations. Productivity will be low, code hard to analyze and faults hard to fix. Unexpected side effects of changes are likely, and as you have found, regression testing non-existent- Maintaining Legacy code is slow and hard - thats why so many developers run off to Green Fields projects. I can be rewarding, but only if you reset your expectations. When you start work on a defect, start by staying focused on three things - What the code does now, not introducing unexpected side effects and what it should do when fixed. You may find that code duplication is better than unexpected side effects..... Without decent tests and requirements, introducing regression is often the biggest sin of all.Always strive to leave the code in a better state than you found it, but be careful not to change its behavior except where required. 