Re: Cost of leaving debug statements in code

You have keenly defined the benefit of leaving the code in. What really needs
to be defined is the meaning of cost. Several options come to mind:

Human cost: What is the toll taken on the beepered souls supporting the world
in the middle of the night. These invisible giants deserve maximum respect and
support (since I am one).

Dollar cost: What is the comparative cost of bumping up your server power to
offset the overhead of leaving the debug code in? Usually way less than the
human cost of taking the code out.

Time cost: If your processing window is fixed and your jobs cannot fit, you
have to choose between human cost and dollar cost. Do you take the code out
to shave seconds off the job time and save upgrading your server, or do you
upgrade your server and delay burning out your beepered souls?

I guess you can see which side of this issue I am on, but don't be mistaken:
I am both a beepered soul and a manager. The human costs are way more important than saving a few hardware dollars.

-- 
+-----------------------------------------------------
| Dan Townsend, Supervising Database Architect
| EBMUD Enterprise Object Designer
| mailto:townsend_at_ebmud.com
+-----------------------------------------------------

Mark Everhart wrote:


> 

> Debate raging in current organization about the cost vs benefit of leaving

> debug output statements in production code.  Currently, a private Boolean

> variable can be set On or Off by using public procedures.  This variable is

> evaluated and if True then a debug package is called to output values of

> variables or whatever.

> 

> The argument rages over the cost of evaluating the Boolean variable at

> numerous places in the code.  Obviously, the poor souls manning the beepers

> would like to have the option of re-running a production job that goes down

> with the debug set on, so they can evaulate more accurately the cause of a

> problem, fix it, and go back to sleep or whatever.