Thursday, August 31, 2006

Do I ever agree with this...

Stumbled on this posting by Linus Torvalds.  I cannot remember the last time I fired up a debugger to debug a problem.  I have demonstrated the debugger for PL/SQL in Jdeveloper/SQL Developer, but I've never used it.  I believe the last time I used a debugger for real was in 1992.  I gave up, threw it (the debugger) away.  It was a multi-threaded Ada application and when run inside the debugger - it would work fine.  Outside of the debugger - it would fail.  This would happen to single threaded programs too (things just run differently in the artificial environment of the debugger).  I made the developer redo their code heavily instrumented - and we solved the insolvable problem in minutes afterwards.  I've written about this art of instrumentation many times (here is one).  I think this guy is definitely on the right track.

The reason I don't like debuggers in general - I don't think stepping through code a line at a time is a good thing.  You are hoping against hope that the problem will just "come out and hit you smack in the face".  It is like the difference between touch typing and hunt and peck typing.  Using a debugger - you are hunting and pecking.  You don't necessarily have a good idea where to look, what to look for - you are just looking for something to "go wrong".

I've said "debuggers are for wimps".  In my opinion if you are forced into using one (as a crutch), it probably means you don't have a really good understanding of the code (you might find and fix one bug in the debugger, but miss the 500 other bugs sitting there) and haven't been programming defensively.  You become dependent on this debugger thing to find your problems - and when it can't (and they can't many times) you get totally stuck, the problem becomes intractable, insolvable. (this seems to be a major failing with many developers - the inability to perform good problem determination, to create test cases, to whittle the problem back to its bare essentials.  It is the single more important skill a developer can have.)

In the 'real code' that I've written (not the quickie demos I do on asktom), literally every other line of developed code is "debug/instrumentation code".  I like to say that good developers write two bits of code:

  • The code they want to
  • The code they have to

But then go a bit further and say that the code they want to write is the defensive code, the instrumentation/trace code.  The code they have to write is the code the end user is interested in - to the developer that code that does "file/open" in their application - that is the stuff they had to write.  The code before and after the "file/open" bit of code that can be used to diagnose issues, validate return values, validate inputs - double, triple check everything - that is the code they want to write.

The reason they want to write that "debug/instrumentation" code?  So they don't have to spend the rest of their natural lives maintaining and debugging their first bit of production code.  Which, if they do not make it traceable - they will be. 

Once upon a time ago, I wrote a utility called "OWAREPL" - it was the OWA Replacement "cartridge".  I wrote it for OWS 2.0 (Oracle Web Server 2.0 - which came right after OIS 1.0 (Oracle Internet Server) and right before OWS 2.1.1, OWAS (Oracle Web Application Server) 3.0, OAS (Oracle Application Server) 4.0 and then AS (just Application Server) now...  So, this was about 10 years ago (it later became the foundation for the webdb lightweight listener and then mod_plsql).  50% of this code was debug/trace code - easily, if not more.  It was downloaded and used thousands of times.  And not once did I have to arrive on site somewhere to debug this code - if something went wrong, I just asked them to turn on tracing for specific modules (a configuration parameter) and send me the trace file.  We fixed every problem 100% of the time in this fashion.

Sort of like what happens with Oracle, it is fully instrumented.  Have a problem? Get a trace.  V$ tables - instrumentation.  SQL_TRACE=TRUE, debug/trace stuff.

But anyway - read the rant by Linus - well said.



Anonymous Josh said....

There is definately something to be said about using your "skillset" to solve problems. Debuggers can be great in a pinch, and sometimes you get lucky. But it is really a training wheel of sorts, that can keep you from fine tuning your troubleshooting skills.

Thu Aug 31, 12:03:00 PM EDT  

Anonymous Anonymous said....

We don't think you're "not a nice" guy like Torvalds thinks of himself!

Thu Aug 31, 12:42:00 PM EDT  

Blogger Thomas Kyte said....

"not a nice"....

it depends :)

I just sent an email in response to someone sending me code that read:

please read this
and NEVER use when others like you have - all you accomplished there is to HIDE THE LINE NUMBER WHENCE THE ERROR ACTUALLY OCCURS.

return codes - they are useless, stop it. Let the exceptions that you cannot deal with propagate out.

I frankly stopped reading the code when I hit that. I refuse to read it any further, that is a bug to me that needs be fixed.

It was a big old when others that wasn't followed by a RAISE (no logging of the error or anything, just hid the error)

I'll bet you that person doesn't think I'm nice right now (maybe in a couple of years in retrospect they will...)

Thu Aug 31, 12:54:00 PM EDT  

Anonymous Oliver said....

I completely agree. I also feel the same about products like TOAD, for example - no disrespect to the vendor it is a really excellent piece of software. However, it also can become a "crutch" and I get really annoyed when people tell me they cannot add a datafile, extend a tablespace or whatever because they don't have a copy of TOAD!

Thu Aug 31, 12:57:00 PM EDT  

Anonymous Anonymous said....

I am just a newbie when compared to all of you people out here. When I started out, I did use the debugger quite a lot. But when I switched from my previous job to the current one, I stopped using the debugger for various reasons(not enough privileges, no one else in my team did it.. etc...). Initially, I was peeved about this, but in retrospect, I think it was a good thing.
I have "configured" the debugger recently and I won't say its a terrible thing to have. It certainly helps in certain situations like finding those silly mistakes.. especially the copy paste kind.

Thu Aug 31, 01:52:00 PM EDT  

Blogger Joel Garry said....

OK, I'm working on an inquiry program written in a 4GL, not SQL (but generates SQL with OCI). It has 13000 lines of code (plus calls out to other code). I'm working on another similar program that looks at the same data but puts out slightly wrong information.

I can hit ctrl-c and be put in a debugger with a screen mode that shows exactly what code is running at that point in each program. I can set watch points for particular variables if I want.

That may be a crutch, but the alternative would be to hack up copies of the programs with a bunch of error message output - now that would be hit and miss.

This debugger, simple as it is, is the instrumentation. It's not training wheels, it's simply a tool to make the maintenance guy's job easier. Doesn't everyone wish they could watch the code they're running get executed? Why should people be relegated to digging through 10046 traces after the fact, just to get part of what they need to know?

Saying "tough noogies, go back and rewrite 500 man-years of code" is not very realistic outside of old-tyme linux kernel development.

verification: ennyc

Thu Aug 31, 01:57:00 PM EDT  

Blogger Thomas Kyte said....

The debugger is not instrumentation.

Do that in production someday? I've never been allowed to install and fire up my debugger on a production install of something.

But - as long as the code is instrumented - they always let me update a row in a table (turning it on) for some reason.

... Doesn't everyone wish they could watch the code they're running get executed? ....

Not a chance, because in a true situation you have dozen's/hundreds of concurrent threads/processes going on and the race condition you hit once in a blue moon - just never happens when you are sitting there.

I'm all about defensive coding, not trying to figure out what the heck is happening after the fact.

And don't forget - good advice doesn't always have to be RETROACTIVE. If the only tool you have available is a debugger - so be it I guess. However, if you want to do it right into the future... Think about writing code DEFENSIVELY.

I'm not saying to dig through a 10046 level 12 trace - I do that for TUNING, rarely for debugging (but hey, it works there from time to time, mostly as the output of a user friendly tkprof report though - don't use hyperbole here - you know what tools there are)..

Thu Aug 31, 02:07:00 PM EDT  

Anonymous Todor said....

Well, for me - the debugger is just another option to deal with a problem. And it could be very usefull if you treat like like that - another option. I actually use it like "last resort" - when I run out of ideas what the problem could be and how to look for it. Which means I do not use it very offen.

The reality is that most of the time we need to deal with uninstrumented and poorly documented code written by somebody else - and then the debugger could really help to get an idea of how that code works.

Thu Aug 31, 03:32:00 PM EDT  

Anonymous Anonymous said....


I find debuggers VERY useful when I learn a new language. I started programming without any type of technical degree. I took some computer science classes a few years ago and I found I learned C alot faster by stepping through a debugger. When you learn a new language error messages don't even make sense to you. After you get good at it, you dont' need it. However, I think its a very useful tool to speed up your learning process.

Also, when you write your next book can you include a detailed section on instrumentation that includes how to instrument. Instrumenting vs. exception handling. What you should intrument? Should you instrument certain things for batches and certain things for OLTPs?

Some examples would be very helpful. I agree with instrumenting. Its hard to get peole to do it. If I have to convince people to do something, sometimes the easiest thing to do is grab one of your books and see 'tom agrees with me'. Putting this in your next book might save alot of us alot of effort arguing with people...

Thu Aug 31, 04:40:00 PM EDT  

Anonymous Anonymous said....

Can you link or post an example of what you consider to be well-instrumented code? You say almost every other line is debug/instrumentation -- I don't think I've ever seen what that looks like.

Thu Aug 31, 04:58:00 PM EDT  

Blogger Thomas Kyte said....

instrumentation is definitely in the table of contents for the next book - yes.

to peek at some of my old instrumented code (you'll know the download page is old - it uses a really old email address for me AND it has the *blink* tag!) you can see:


look at the debugf macro first (in the .h file). debugf would always print out the source code file, the line number, the time and the message. You could trace by a list of modules (source code files) or all modules.

Also look at log4j and log4plsql (search google for them).

Also think about sql_trace=true, setting oracle events, the trace files generated when something goes wrong.

Also, think about v$ tables - these are all examples of instrumented code.

Thu Aug 31, 05:07:00 PM EDT  

Anonymous Mariano said....

I find conditional compilation the best tool for instrumenting my code.
I wish you let us know what you think about conditional compilation someday (maybe in your next book?).

You book convince me that instrumenting is a good thing: working on bugs now is easy and I can find my problems really quick.

Thu Aug 31, 07:12:00 PM EDT  

Anonymous tobias said....

A very interesting performance orientated instrumentation/tracing set of packages from Hotsos (Cary Milsap et al) is open source:

Thu Aug 31, 09:34:00 PM EDT  

Blogger Noons said....

This book:
ISBN - 0201179288, C Traps and Pitfalls

and the excellent

Expert C Programming

set me on the right track, many years ago. Before those it was the seminal work by Jon Bentley that guided me.

Truly timeless texts on how to approach programming, not just in C.

And how to ensure a debugger is almost never needed.

I think in over 30 years of programming I've had to use a debugger twice:

once, to get rid of a pesky OS problem I couldn't isolate any other way - different ring execution levels

twice, to find a weird and obscure off-by-one problem in a dynamic memory tree-walk I wrote ages ago to convert Application Foundation forms to Forms 3.

Fri Sep 01, 01:53:00 AM EDT  

Anonymous Matthias Rogel said....

agree 100%

real programmers don't use debuggers
real programmers don't read books

Fri Sep 01, 02:46:00 AM EDT  

Anonymous Giovanni said....

what you say is true, but sometimes you inherit someone's else code that is poorly instrumented (or not instrumented at all). In these occasions debuggers can help to locate the problems quickly. Obviously the fix must be a program more instrumented than the previous one.

Fri Sep 01, 03:09:00 AM EDT  

Anonymous Anonymous said....

I disagree with you Tom. The debugger is another tool that can be useful; but maybe we have just seen different code.

Of course we can be asked to maintain code we don't understand. This is certainly not ideal, but at the end of the day, some of us are just asked to jump in and get things working.

When you have tens of thousands of lines of uninstrumented code where the framework architect took object programming to the next level in a language like powerbuilder, the debugger can be the quickest solution. This of course leads to more crap code in the crap application, but there is simply no interest or investment in rewriting a working program.

Yes, I subscribe to the time proven theory of instrumentation or a few simple output lines and some intuition, but I keep every tool I can in my tool box.

Fri Sep 01, 04:30:00 AM EDT  

Anonymous Anonymous said....


Fri Sep 01, 04:32:00 AM EDT  

Anonymous Anonymous said....


I generally agree with your stance on debuggers, but there is one case where I find them to be very useful: when you have to debug and fix somebody else's sloppy, un-instrumented code. It gives you a starting point and a bit of insight into the program flow.


Fri Sep 01, 09:26:00 AM EDT  

Anonymous Mike said....

Obviously a topic with strong opinions and interest.

It's interesting to me that the real developers (who are smart and I have lots of respect for!) throw out a tool and refuse to use it no matter what.

I know it can be abused. I know there are limits to the tool. I know that it doesn't fix everything. Instrumentation is a good thing.

There have been cases, however, that the debugger has helped me find a problem and fix it before the real developers have any clue what's going on.

In my opinion, it's better than the real developers working through the night using their skill and sweating bullets because it's broken and has to work by 8 in the morning. It gives me more time to test my solution and understand the single function that failed.

Same with IDE's. I'll use any tool that helps me.

Fri Sep 01, 01:25:00 PM EDT  

Anonymous stephan said....

"real programmers don't read books"???

hmm, maybe they just write them?

Tue Sep 05, 11:13:00 AM EDT  

Anonymous Linus Torvalds said....

and, not to forget:

Real Men don't make backups. They upload it via ftp and let the world mirror it.

Wed Sep 06, 06:09:00 AM EDT  

Anonymous Anonymous said....

I originally wrote this "7 secrets" for an internal document many years ago. Since then things (wrt point 4) have got worse because peopel react by just peppering their code with Try..Catch which is all well and good but is much slower and uglier than simply testing for fault conditions in advance.

Anyway - thanks for the link, it has revived an old article and provided a lot of comments

Wed Sep 06, 08:25:00 AM EDT  


<< Home