I've inherited a project with a fairly large codebase, and the original developer rarely, if ever, replies to emails. There's a ton of different ways to do some things in it, and I don't know all of them. A lot of duplicated code along these paths (rather than functions included by, say, 5 pages that do relatively the same thing, it's code copied across 5 pages), and some subtle issues in the database (we've all heard of spaghetti code, but have you ever heard of a spaghetti database?)

All of this I can deal with most of the time no problem.

The issue is when a client finds a bug somewhere. They'll usually send a screenshot of the ending issue, and say, "Could you take a look at this?" while highlighting the specific thing on the page that's wrong, and sometimes what was expected. Very little more information is given, and trying to talk to them and get more (such as what they did to get the result) is like pulling teeth.

Basically, it boils down to this:

  • Large and complex code base I'm not 100% familiar with
  • Many many ways things can go wrong
  • Very little information on how a bug came to be

Does anybody have any tips, tricks, suggestions, etc. on how to debug this sort of thing?

closed as not constructive by gnat, user40980, Kilian Foth, BЈовић, Dynamic May 19 '13 at 23:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • "Have you ever heard of a spaghetti database?" I once worked at a job where the product's database had been evolving continuously for over ten years, with little to no effort made at refactoring it as the requirements grew (and grew, and grew, and grew). I had a coworker whose entire job boiled down to "Understand the database, create SQL queries for extracting anything useful from it" -- and she was indispensable. I feel your pain. – BlairHippo Oct 21 '10 at 16:14
  • As a complement, [read the "psychic debugging" posts on Raymond Chen's blog](goo.gl/2KIH )! – Wizard79 Oct 22 '10 at 9:47
  • How large is the code base? Ten KLOC or 50 MLOC? – Basile Starynkevitch Jan 20 '15 at 8:00

When I get something like that, I usually demand more information. Not sure how it is where you work, but here if I don't have enough information to reproduce the problem locally, I can send the ticket back marked Cannot Reproduce, with a request for more information, and they know that nothing's getting fixed until I'm able to break it on my end.

If your clients are having trouble with describing steps, ask them for a screencap video. There are a few free products that can create them, such as Jing. It makes it a lot easier when you can watch exactly what they were doing.

EDIT: Jing was a good idea when I wrote this a few years ago. Since then, they've modified their installer to load your system up with "bonus" crapware that you never asked for, so I can no longer recommend it. There are plenty of decent screen recorders around, though.

  • 2
    +1 Sound advice, and I'd expand it to: Can they get the bug to happen reliably, or is it intermittent? If it's happening reliably, can they walk you through the steps they took to get there? – BlairHippo Oct 21 '10 at 16:20
  • 1
    Seeing into log files can help a little. – pramodc84 Dec 17 '10 at 6:44

A good start might be this book.

alt text

I am using the definition below as it sounds like the developer isn't around to support it anymore.

Legacy code is source code that relates to a no-longer supported.

  • Sad part is, this isn't even legacy code. I'm pretty sure most of what I'm working on was started earlier this year. – Tarka Oct 21 '10 at 16:25
  • 3
    @Slokun -- the definition of "Legacy Code" in the book is not entirely the same as the traditional definition of it. It's a very good book. – Austin Salonen Oct 21 '10 at 17:50

I had a similar problem a few years ago and the biggest boost to productivity and code clean-up was integrating bug tracking into the system.

We used Fogbugz (I assume they still do Fogcreek!) and we were able to build an exception handling mechanism where the user could press a button any time an exception was raised and it would get immediately logged into our system -- no more calls and no more screenshots. With this option you take the information you need instead of trying to extract it from the user. Sounds like a variant would do you some good, especially with a screenshot capture option.

The other thing you'll want to start doing is to start adding logging. You may want to go as far as logging every method call with argument values. Since it sounds like you're working with legacy code (code with no tests), this logging will help you add appropriate unit tests so you don't repeat any problems.

  • For a large pre-existing code base, adding good logging is going to be a HELL of a lot of work. +1 because it may prove to be the only viable option if the bugs are intermittent. – BlairHippo Oct 21 '10 at 18:04
  • @BlairHippo: From my experience it is, but that's the price you pay with a codebase he's describing. It's almost as miserable as working in such a codebase to begin with... – Austin Salonen Oct 21 '10 at 18:16
  • Logging is difficult. Adding automated exception logging is trivial, and worth the (minimal) effort a thousand times over. Or at least, it is in Delphi. Not sure what solutions exist for other languages, but it shouldn't be too difficult for any language with decent exception handling. – Mason Wheeler Oct 21 '10 at 19:06

My most earnest advise is to start refactoring where you can. I can not count the number of times I saw a recopy of functionality only to find out that it wasn't 100% a full copy. It was 99.9% copy and 1 small, minor mistake which resulted in a bug. Start adding unit tests to everything and if you have a QA department try to get some automated testing scripts going for those portions of the code you're working.

On the other hand, see how much logging to can inject into the code. That is, if it doesn't have much in the way of logging you can add a flag to the code to start picking up more verbose logging for your own debugging purposes. This is something you can have a user turn on and off if you can get a dialog going. It's helped me more times than I can count. I normally get "it doesn't work" without a picture of the problem. I just say "send me the log file."


Start by writing unit tests. Pick a class or a function and write a set of tests corresponding to how you think it should work. If the tests fail, figure out why. If it is a bug - fix it. If your expectations turn out to be wrong, figure out what the thing actually does and modify the tests accordingly.

Once you have a decent set of working unit tests, you have a safety net for doing some refactoring to make the code cleaner.

Keep iterating until you understand the code base.

Needless to say, this is something you should do ahead of time, not in response to a bug report.

Not the answer you're looking for? Browse other questions tagged or ask your own question.