David Truxall

Wriju has a gread roundup of eBooks/guidance available on CodePlex.

Got my new November Dr. Dobbs issue today. The back column “Swaine’s Flames” has reminded me of some programming “laws” that I have seen before. I have added my own corollaries for each:

Kernighan’s Law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

My corollary: “The developer who’s code that you inherit believed they were twice as smart as they really are.”

Eagleson’s Law: “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

My corollary: “You can recognize that you have written code to solve a particular problem but will be unable to locate the specific instance you recall.”

We all spend lots of time delving into the technical aspects of our work, but don’t forget who we are creating all these wonderful apps for. You need to design your apps to work for the users, not create apps that the users need to work to use.

Required Reading: Four Modes of Seeking Information and How to Design for Them

A recent post by Lamont Harrington asks about the proper methods for exception handling:

“Should exceptions be bubbled up the call stack and be unwound by a “global“ exception handling layer and logged appropriately, or should some form of exception handling happen at the point of code execution? “

I think a proper design does both. There are cases where the exception can be handled in the procedure where it occurs. Good defensive coding trys to identify as many of those cases as possible and handle them (Actually, good requirements and design should identify many of these situations). Obviously, you cannot foresee all circumstances so the “global” handling is necessary as well. Personally, I don’t like to repeatedly re-throw an exception up the call stack because the procedures don’t handle it specifically, I would rather let it bubble up on its own and handle it at the end. Re-throwing tends to bury the real source of the error when you are trying to debug a problem in a multi-tier application.

I have to add a plug for the Exception Managment application block. It has been very good to me so far.

There a fascinating discussion going on at Tim Sneath’s blog about the functionality of the business layer moving to compiled stored procedures in Yukon. At least in my project, we have been doing that very thing and struggled with the n-Tier issue as a result. In our case, the database is Oracle 8i, and the application is/was ASP, which we are now converting to .Net. We have some very complex business logic encapsulated in PL/SQL stored procedures. There were two concrete reasons for the decision:

1. The amount of data that would need to be transferred was huge.
2. Oracle is more efficient than ASP code at many of the operations involved.

With ADO.Net, some of the ineffieciency may be addressed, but the database is designed for efficiency at certain operations that ADO.Net won’t be able to match.

We did not need to approach this from a scalability issue, as the app receives hundreds of hits per hour, not thousands or more. I still think it will scale OK as your business objects will have much shorter life spans and you can still pool and queue database connection objects if needed due to long-running stored procedures.