Sanding our assholes with 150 grit. Slowly. Lovingly.

Why "the pointy haired boss" should stay away from the code...

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 ;)
Permalink Phibian 
August 23rd, 2005
did anyone else feel a little dumber after they read this?
Permalink  
August 23rd, 2005
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.
Permalink Cory Foy 
August 23rd, 2005
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>.
Permalink Phibian 
August 23rd, 2005
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.
Permalink Rich Rogers 
August 23rd, 2005
don't forget step 11: charging those 31 minutes and 42 seconds to the client as debugging maintenance...
Permalink Kenny 
August 23rd, 2005
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.
Permalink I am Jack's finance frustrations 
August 23rd, 2005
Phibian, don't be too hard on yourself. At least you did steps eight and nine. Some developers wouldn't have.
Permalink Kyralessa 
August 23rd, 2005
Hey, didn't you mean 'Undo Checkout' for steps eight and nine?

If not, I've got a managerial task for you.
Permalink Jeff Barton 
August 23rd, 2005
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.
Permalink Sathyaish Chakravarthy 
August 23rd, 2005
(6) ???
(7) Profit!
Permalink Rich Rogers 
August 24th, 2005
6) Implement a value managed end-to-end process.
Permalink Mat Hall 
August 24th, 2005
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 :)
Permalink Phibian 
August 24th, 2005

This topic was orginally posted to the off-topic forum of the
Joel on Software discussion board.

Other topics: August, 2005 Other topics: August, 2005 Recent topics Recent topics