What is the longest time you spent debugging a problem

Question

What is the long time you have spent debugging a particular problem?

Was the solution trivial in hindsight?

How did management react when it took so long?

Answer 1

2 weeks

Not trivial.

I think I got a raise for that one. The checkin/commit comment was probably a page or two long.

Answer 2

I think that most solutions are trivial in hindsight. Finding defects is an artform onto itself, sometimes.

About a year ago, I spent three weeks correcting a problem with our production product. It was performance related, and there were multiple things to be addressed. Most of them were the direct results of bad coding habits or faulty logic. They were easy to find, a little tricky to correct (because of a lack of decent architecture), and even harder to convince the original developers that they had done something improperly in the first place.

I find that performance-related issues are the trickiest to work with, because of their nature. The place that you see performance issues is not always the place that the underlying issues actually are.

Answer 3

Ive spent a few hours to most of a day trying to figure out some Hibernate issues before.

Answer 4

Over three weeks, if I remember correctly. The problem was trivial, but didn't make sense. I was adding multi-lingual support (Chinese to be precise) to a Symbian application. As a rule, problems that crop up with Symbian do probably tend to take a long time before an obvious or not solution pops up.

Answer 5

Two months. The problem turned out to be a major design flaw that had no easy fix. It took two months just to identify the problem because it could only be replicated at one client's site.

Answer 6

Several times, four or five days.

The hardest was at a time when I had just switched from being a mainframe Cobol programmer to being a Windows C programmer. New job, new people, shaky confidence.

One hard part about that switch was that the mainframe platform was so stable and solid as compared to the Windows programming environment. For example, I remember when I first heard the phrase "compiler bug", I couldn't comprehend it. I couldn't comprehend that the compiler itself might be injecting an error into my code even though the source code I had written was correct when I executed it mentally.

When you are new at your job, uncertain about your qualifications, it can feel very awful and lonely to be on day 3 or 4 of a bug. It's so much better when you can work on a team so that at least your teammates can testify that the bug is truly difficult and that you are not incompetent.

When you are trusted employee with nothing to prove, when you can enjoy the detective work free from anxiety about what others are thinking of you, then solving a bug after several days working on it is one of the biggest rewards of our profession.

Answer 7

I worked a couple months on an iterative algorithm designed by someone else that attempted to solve a problem ideally solved by calculus of variations, but due to time constraints had to be solved iteratively. The problem was that the algorithm worked in 99.9% of cases, but there were a few corner cases that caused significant problems for our customers. This was definitely not trivial.

Another problem I worked on took about a month that was a device driver issue. It was not trivial because nobody I could find had the same device driver constraints we did, so I couldn't find any previous work related to what I was doing -- even when scouring the web. The problem probably could have been solved in about half the time if I was more familiar with device drivers though. This was the first big device driver issue I had worked on and there was a lot of time spent learning about limitations about programming drivers.

Answer 8

Full time: two weeks. (actually, we never fixed it as it seemed to be a bug in the C Run-time library; we found a work around)

Occasionally looking at it: 1.5 years. It wasn't so much a bug, as much as I just didn't know how to do it, so I kept trying different things.

Answer 9

Even though I like debugging , there were 4 days in which I didn't enjoy it one bit.

Answer 10

I've spent about 2 months on a particular problem a couple of times.

The solution was trivial in one case, removing string concatenatations in classic ASP, while the other hasn't been totally resolved yet but seems to have gone away.

In the ASP case the reaction was that we'd have to put the change in gradually as otherwise I'd be making thousands of changes in a release as there were many many many concatenations to change where a line like:

strTextString = "Blah blah blah " & " doo doo doo" & "Whatever dude"

became a line without concatenation afterward.

In the other case, I cleaned up what was an initial implementation that had a few odd ways that things could be handled and somehow that fixed some things.

Answer 11

I think I ran into a non-trivial bug with my group's senior design project (I was one of the lead developers) that took a week to resolve. Getting an A on our project was a nice reward for that time, though.

In more recent times, I hit a bug a few weeks ago that turned out to be extra whitespace in a non-trivial location. Took a full workday to figure that out.