Just spent 31 minutes and 42 seconds tearing my hair out trying to figure out why a report doesn't add up.

Step one. Find a simple case. 30 + 60.50 + 42 != 72.5
Step two. Determine that since 30 + 42 = 72, probably it's the 60.5 that's the problem. (clue 1 - my math is off already because I'm missing 0.5)
Step three. Try running the database query generated by the report directly and see what results I get
Step four. Ask a "real" programmer for help. Tell programmer that I've already tried most of the suggestions.
Step five. Add up results manually and get the same result.
Step six. Both of us stare at the screen wondering what's wrong for a bit.
Step seven. Realize that 30 - 60.50 - 42 does actually equal -72.50. D'oh!

Step eight. Remove changes made while trying to solve the "problem".
Step nine. Remove debugging code and close the bug.
Step ten. Decide to do something more "managerial" for the rest of the day, for the sake of my poor team ;)

did anyone else feel a little dumber after they read this?

Not at all. Made me wish finding a bug in our reports was like that. Ours was like:

1) Sales discoveres minor bug where a count is off by 1.
2) Verify report is actually off by 1
3) Check report tables, which show it is off by 1
4) Dig into the views, which show they are off by 1
5) Look at the stored procs which generated the data for the views, showing they are correct
6) Look at the views the stored procedures generate the *other* views from and show they are off by 1.
7) Look at the stored procs, which pull the data from a restored database into the views the other stored procs use to generate the other views, and they are fine.
8) realize that a field was added to the production database that the restore script somehow doesn't account for.
9) Account for the field, and rerun the sync procs.
10) See all is happy and right again.

I was never happier to be off of a project than that one.

Which is better: to have sales (or customers) find a bug, or to have your manager invent one?

Obviously I prefer the invention from a customer relations point of view, but from a "look I can code / solve bugs too" this demonstration fell a little flat <g>.

Phibian's original post is a rather insightful look into the way a lot of developers do debugging by random changes without ever understanding the fundamentals.

don't forget step 11: charging those 31 minutes and 42 seconds to the client as debugging maintenance...

Mine was always more along the lines of:

1) Create some kind of report process
2) Give it to the requestor
3) Receive complaints of innaccuracy
4) Review report
5) Review 'control' report
6) Find out that neither is 'right' due to bastardization of system fields and/or manual practices
7) Beat head against wall

I always wanted to do this for fun:

8) Insert random number generator and tell them it is fixed.

Phibian, don't be too hard on yourself. At least you did steps eight and nine. Some developers wouldn't have.

Hey, didn't you mean 'Undo Checkout' for steps eight and nine?

If not, I've got a managerial task for you.

Mine is more like a paradigm.

(1) Create paradigm
(2) Say 'paradigm' three times a day at least
(3) Synergize the strategies
(4) Devise knowlege optimization initiatives
(5) Mobilize organizational structural energies for leveraging the implanted knowledge management processes.

(6) ???
(7) Profit!

6) Implement a value managed end-to-end process.

Actually, I didn't get as far as checking in my code.

Our policy is to remove all "debugging" steps and make sure the bug is actually fixed before checking in any code :)