Thursday, October 04, 2007

A great article...

In order to be good, you have to realize how bad you are.

Interesting concept.  I believe it to be 100% accurate.  Everyone makes mistakes, all of the time.  I like his overall approach, lots of assertions (now waiting for the emails/comments asking "what's an assertion" :) ), pick a language that makes sense - not one that is "just so cool", and as he says "be a testing masochist".

I would add one thing: make every other line of developed code some sort of debug/trace output, instrument to death. And keep it in for production - they do not actually let you drop in a debug version of your code there, you need to always be running the debug version (just like the Oracle database does...)

I really enjoyed his talk on exception handling.  It drives me utterly nuts how people abuse (not use, abuse) error handling.  He talks of a team that was plagued by runtime errors, so - what did they do?

... I’d joined a development project where the original developers had so many problems with run-time exceptions that they simply starting including “null exception handlers”, i.e., catch all unexpected exceptions, suppress them, and keep on going. Needless to say, the system would run fine for awhile, sometimes hours, and then slowly start to...hmm..."veer off". ...

Oh, if I could get them to remove "when others" from PL/SQL - I'd be a happy camper (at least in 11g, if you have a when others that is NOT followed by RAISE or RAISE_APPLICATION_ERROR(), the compiler will WARN YOU).  You know how many times I've found bugs simply by looking for when others in code?  If I had a nickel....

I'll join the chorus of comments on that article - My name is Tom and I'm a terrible programmer :)

(read the comments on that link, it is funny how many people did not get it.)



Anonymous Robert said....

meh there you go with your preaching on "when others" & instrumentation again


Thu Oct 04, 11:44:00 AM EDT  

Blogger Kim Berg Hansen said....

Brilliant link - thanks, Tom.

If I know that I will fail and plan for it, there's a chance that the end result fail less often.

Personally I'm probably just a bad developer and not quite at the terrible level yet - I have this disturbing tendency to try and think out the code before touching the keyboard thus trying to be less terrible :-)

Thu Oct 04, 12:00:00 PM EDT  

Blogger Joel Garry said....

And the Terrible DBA equivalent - you will blow it, always be ready to recover!

I wonder how long until people start baring their souls in job interviews...

word: pigdoqkx

Thu Oct 04, 01:44:00 PM EDT  

Blogger Dominic said....

However, in order to profit from your mistakes you have to be aware of them. Goes back to the "Unskilled and Unaware of It" studies from Cornell (

Thu Oct 04, 02:29:00 PM EDT  

Blogger Rob Zijlstra said....

Is this article not a long version of : 'always remember Murphy's first law!' ?
The program language one uses has nothing to do with the whole point of the article.

Rob Zijlstra

Fri Oct 05, 05:41:00 AM EDT  

Anonymous Jack said....

Okay, Tom.

Define assertions in the context of the article.

Fri Oct 05, 07:37:00 AM EDT  

Blogger Thomas Kyte said....

Define assertions in the context of the article.

in C, it would look like the following for a routine that expected a number between 1 and 5 as input:
[tkyte@dellpe ~]$ cat test.c
#include "stdlib.h"
#include "assert.h"

void foo( int x )
assert( x >= 1 && x <= 5 );
printf( "X=%d is OK!!\n", x );

int main( int argc, char * argv[] )
foo( 1 );
foo( 0 );
return 0;
[tkyte@dellpe ~]$ ./test
X=1 is OK!!
test: test.c:6: foo: Assertion `x >= 1 && x <= 5' failed.
[tkyte@dellpe ~]$

the assertion failed, the program automagically bails - we got into a situation whereby we could not recover.

the equivalent of an ora-600

Fri Oct 05, 08:06:00 AM EDT  

Blogger JCFlack said....

I like the reference to Ada - what is the mother of PL/SQL? Yes - Ada. And PL/SQL has most of Ada's good points.

Fri Oct 05, 02:08:00 PM EDT  

Anonymous doug c said....

I liked that article - but I do know several developers who would have complete reversed that C++ and Java comment. Java allows you to do some funny things and C++ is the "better" language. Anyone have a comment about that? I don't know..

Sun Oct 07, 09:32:00 PM EDT  

Anonymous Anonymous said....

Tom you must be thinking twice before putting such statements

“My name is Tom and I'm a terrible programmer :)” …

I can end it like this

“And that’s why I always put lots of bug in my code :( ...”

It some time’s becomes an excuse for our mistakes. Which is unacceptable right? We all are developers and we make our living by that and we should be good in what we do and always look to be “better”. BETTER is the work we should be holding on to.

I would like to say

“I am Karthick, and I am looking forward to become a better programmer today than what I was yesterday :)”

Also never believe on best there is nothing like that it’s just a myth.

Mon Oct 08, 08:40:00 AM EDT  

Blogger Jared said....

One of the comments in the blog you referenced mentioned "Code Complete" by Steve McConnell.

This is a fantastic book. Anyone that writes any kind of code should have a copy, and read it.

Personally, I know I need to read it again. :)

This book focuses on C as a programming language, but the lessons taught go far beyond C.

Mon Oct 08, 01:27:00 PM EDT  

Blogger Thomas Kyte said....

to anonymous who wrote "I am Karthick"

I'm pretty sure you missed the point of the article.

The author is one of the best programmers out there.

The kind that knows they make mistakes.

The kind that knows "stuff happens - DO NOT HIDE IT WITH BAD EXCEPTION HANDLING"

The kind whose code I would not mind inheriting.

The kind with a spot of humbleness.

You entirely missed the point if you think the statement "and I'm a terrible programmer" was an excuse.

I think you either entirely did not get it - or - you did not read the article at all.

If you want to achieve the goal you stated:

"I am Karthick, and I am looking forward to become a better programmer today than what I was yesterday :)"

You should immediately go back, re-read that article, implement the ideas in it, add a heavy dose of instrumentation and you'll be well on your way.

He is simply saying "we make mistakes, we are not perfect, we should code DEFENSIVELY therefore".

And he is about as correct as a person can be.

Mon Oct 08, 04:15:00 PM EDT  

Blogger bdm said....


Mon Oct 08, 09:29:00 PM EDT  

Anonymous Boneist said....

Hi Tom, sorry off-topic here, but I saw this and thought of you...

Wed Oct 10, 05:37:00 AM EDT  

Blogger Steven said....

Tom (or anyone): in PL/SQL when you have debug/trace/instrumentation every line or so, um, can you be more specific?

How do you turn it off and on in production?

Do you read a value in a debug table?

if #debug = TRUE then (do_stuff) end if;

Do you use DBMS_OUTPUT? (I doubt it) Preprocessor directives (unlikely) Recompilation?


Fri Oct 12, 02:52:00 PM EDT  

Blogger Thomas Kyte said....

I use a 'hand written' package debug - with a "f" function (written up in Beginning Oracle Programming and Expert one on one Oracle).

today, you might use

log4plsql a bit of freeware.

Fri Oct 12, 02:55:00 PM EDT  

Blogger Phil said....


If anybody thinks of ending that with "NULL" they should be shot on sight. Or at least be shown the error of their ways.

HOWEVER that doesn't mean the clause shouldn't exist.

I use the WHEN OTHERS clause to call my logging function [which wraps log4plsql :) ] with diagnostic information that would be useful in a production setting (i.e. when my log level isn't set to DEBUG).

And then I RAISE :)

Sun Oct 14, 06:12:00 AM EDT  

Blogger Thomas Kyte said....

Phil said...

Oh, trust me, I know there are valid uses of WHEN OTHERS

Just like there are valid uses of triggers.

Just like there are valid uses of autonomous transaction.

However, they are so universally misapplied - that the quality of code every where would rise a bit if they did not exist.

As the cliché goes "Just enough rope to hang themselves with..."

Sun Oct 14, 09:43:00 AM EDT  


<< Home