DC> Just wondering how normal or abnormal I am.
 DC> When I implement a feature or part of it, I compile the program to see
 DC> if that part of it is actually going to run, and if it doesn't run as
 DC> expected I do further testing or learning on it. This can be every few
 DC> minutes of course, and can take some time, but I believe it helps
 DC> ensure that the beta release is quite close to bug-free. 
 DC> Does anyone else program like this? Does any one else have any
 DC> suggestions? 
   It's a matter of Risk Management - how much you wish to spend (time,
effort, money) to assure against having to deal with an (undiscovered)
problem after it's gotten out to the customer base (where it's _most_
expensive to handle).  The smart, experienced developers will (have
learned) that a little testing (1) won't find all the errors, (2) cannot
presume to really flush out problems (it's impossible to exhaustively
test _anything_ to guarantee it's absolutely free of errors), and (3) is
only part of a rigorous development process which is needed which itself
will prove the program's correctness.
   (The acceptance of) this overall concept has been long and difficult
for American programmers (I know you're not), because we used to believe
you could "test out" the errors.  Now, international standards, Like ISO
9001, SEI Assessments, and such are proving that there's a better way to
develop things (software being only one), and that it's more important
to develop and maintain a _process_ for development which forces things
to be done correctly - at each step, along the way, and which will find
the errors (known as defects) early in the development cycle - where
it's cheaper to fix the problems.
   There are standard metrics which show that for a given number of
lines of code (LOC), there will be a rather fixed number of defects,
regardless of who's doing the work, what the application is, or other
variables you'd think would matter.  Thus, finding them early as
possible makes great sense, since the number is somewhat finite.  It is
possible to institute a development process, albeit a major change to
most programmers and companies, which will better the overall
implementation cycle by reducing errors, time to deliver, job
dissatisfaction, along with creating better morale and job satisfaction
(who really likes to spend his/her time fixing problems, instead of
developing new stuff?).
   As a career programmer of >35 years, I certainly had my struggles
with this when it was mandated at my company - everyone did.  However,
I've seen it work and be effective, and I now embrace it.  It's strange,
but it's potent.
   How does this answer your question?  Not well, I'd bet, but it's an
answer you should think about, read up on, and one which you'll no doubt
be forced into if you stay with programming at all - the whole world is
using it.  The key is that you spend whatever time is needed to
thoroughly design, inspect/reinspect your work all through the project
(not just the coding), so that you're sure of what you're doing and how
you're doing it, and finding/fixing the errors along the way - so that
"testing" is little more than compile/linking and packaging (of a now
working product).  In essence, with an effective development process,
you shouldn't have to do much testing at all...
... Hang mistletoe at the airport! Kiss your luggage good-bye!
--- OMX/Blue Wave/DOS v2.20
---------------