Friday, September 01, 2006

Successful Programming

Ran across this paper the other day - 7 'secrets' of successful programming.  I liked it - sort of fit in with my debugger rant from yesterday - especially point number four which I'm going to copy and quote here:

4. Expect the unexpected and deal with it

Before you open a file, make sure that the file is present. Before you set focus to a control, make sure that the control is visible and enabled. Try to work out what conditions could cause your code to fail and test for them before they cause the program to fall over.

Expect the unexpected - deal with it.  Words of wisdom and ties in nicely with "instrumentation".  If you get something totally unexpected in your code - but have no way to record that fact, to transmit that bit of data back to you (or to the DBA or the team that maintains the code or the helpdesk or ...) you lose.  Part of instrumenting is recording the unexpected - that is sometimes the best you can do to "deal with it".  Your program very likely might have to "fall over" (gracefully! not with a segmentation fault or a "dr. watson") still - but you'll have recorded, or at least have the ability to record, why.  Sort of like an Oracle trace file written during an ORA-00600.  It would be better than just popping up some error dialog for the end user (see some classic examples here)

I'm putting together a couple of "do not try this at home" talks for upcoming events (sort of worst practices if you will).  Hence you might see me talking more about what not to do than usual.  Sort of like the "when others then null;" ranting I did not too long ago :)

Look for me in an upcoming article.  Alex Papadimoulis will be taking a break and asked for some "guest editors" to provide content for while he is gone. 



Blogger Hae-Kwang said....

I really enjoyed yesterday's post, and, as you mentioned, today's seems to fit along nicely with it. I was wondering about if the items mentioned can be applied by newbies, or if it's more efficient for veteran coders. I want to get started on the right track, etc. and was wondering if you had feedback regarding advice, etc. as to how the mentioned techniques, etc. could be applied by newbies if appropriate.

Fri Sep 01, 09:32:00 AM EDT  

Blogger Thomas Kyte said....

The instrumentation approach is something that definitely should be applied by "newbies" - and avoidance of the debugger as well. For, if they learn with the crutch (of a debugger), they'll never be able to be weaned off of it.

I think one of the reasons I'm really good at root cause problem determination (I rather have a knack for it) is because of the way I was taught in the very beginning.

My first programming environment in 1987 was a mainframe environment. We worked on machine "A" (an IBM 3081 machine running VM/CMS). That is where we edited, tested the compilation of code. In order to run it - we had to submit it using JCL to machine "B", a MVS machine, really compile it there and then run it.

No debuggers.
No console.
No nothing - just our sysout output and whatever we wrote to files.

The guy that taught me the ropes taught me instrumentation from day one. I didn't know there was any other way. And when I found out there was - I thought "why"? I tried debuggers and such (yes, there were a time or two they were useful, not in general however) but kept coming back to "write code that helps you maintain the code".

When I wrote GUI programs under windows - the debugger for me because virtually useless. Nothing ever worked the way it did in real life in the debugger. I was back to generating trace output (I had my own hidden "console" window in programs I developed - turn it on and see the trace, turn it off and it went away, but it was ALWAYS there if I needed it).

So yes, I think that "newbies" especially should be following this particular approach.

Fri Sep 01, 09:42:00 AM EDT  

Blogger Hae-Kwang said....

Do you recall resources that you used when you first were taught this method that you can recommend? Something that explains this method to the complete beginner would be tremendously helpful - maybe the topic can be mentioned in one of your future books?

Side note: I didn't realize that the term 'newbie' was an actual word until a few minutes ago when I checked both and I wonder what it takes for a made-up word to become a real one, because I've got a list of them I'd like to see offialized.

Fri Sep 01, 10:06:00 AM EDT  

Anonymous Kevin said....

Personally, I dislike the phrase "expect the unexpected" - it is vague at best and nonsensical at worst. I much prefer "identifiy all assumptions". That's much more straightforward - at each step, the developer isn't asking: "Now, what am I not expecting?"; she's asking "Now, what assumptions am I making about my environment?". The latter seems far more likely to evoke a meaningful response.

My $0.02.

Fri Sep 01, 10:18:00 AM EDT  

Blogger Thomas Kyte said....

Do you recall resources that you used when you first were taught this method that you can recommend?

an experienced mentor who wrote software SUCCESSFULLY for a living :)

Personally, I dislike the phrase

I think I agree with you - it would be better said as "identify all assumptions" or "trust, but verify" :)

Fri Sep 01, 10:24:00 AM EDT  

Blogger Andy Campbell said....

My coding habits changed completly after reading a book by Steve Maguire, "Writing Solid Code", probably about 10 years ago.

The books was aimed at developing C but the principles can be applied anywhere. The author talks about putting Assertions throughout the code checking contents of variables are within the limits you expect, etc, etc. All the sort of stuff mentioned here. My code became much more stable.

It was very easy to read, very recommended if its still in print.


Fri Sep 01, 12:24:00 PM EDT  

Blogger Joel Garry said....

I wonder what it takes for a made-up word to become a real one, because I've got a list of them I'd like to see offialized.

Here's how the OED does it.

There are also pseudodictionaries for the humor-inclined.

There are also many places on the web about word origins. I find pretty entertaining

verification: efffj Same to you, blogger!

Fri Sep 01, 02:01:00 PM EDT  

Anonymous Urs said....

Just tried to open th "classic examples" link. Here's what I got:

Server Error in '/' Application.
Server Too Busy
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Server Too Busy

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[HttpException (0x80004005): Server Too Busy]
System.Web.HttpRuntime.RejectRequestInternal(HttpWorkerRequest wr) +150



Mon Sep 04, 03:26:00 AM EDT  

Blogger Thomas Kyte said....

Urs -

I just linked to an external site, sorry - it appears to have been "not available" at the moment you clicked on it. It does seem OK now.

Mon Sep 04, 08:18:00 AM EDT  

Anonymous Urs said....

Sorry, Tom,

I didn't mean to blame you, just thought this was good instrumentation: "Server too busy".


Mon Sep 04, 08:46:00 AM EDT  

Blogger Thomas Kyte said....

Urs -

ahh, but we have no idea what was dumped on their server do we?

They could well be instumented to death - we don't really know (only they do).

Just like

SQL> select ......
ORA-00600 Internal Error [23faafds][rewq532].....

that is instrumented to create a rather large trace that is not necessarily exposed to the person getting the error.

Mon Sep 04, 08:51:00 AM EDT  

Blogger kabalweg said....

Free Source Codes and Tutorials
Nice post you have here. Out team aims to standrdize our coding style. I think this (The seven secrets of successful programmers) will greatly help us.

Fri Sep 08, 05:59:00 AM EDT  


<< Home