Re: Debugger Rant (was Re: How to debug an Ada program)

["Robert I. Eachus" <rieachus@attbi.com>]

Alexander Kopilovitch wrote:

>>Shrug!  I guess I have internalized a style of programming once known as 
>>"Design to test."  In other words, all (formal) requirements are 
>>testable, and you design and code from day one to make passing those 
>>tests as easy as possible.

> While being absolutely true, this is surprisingly hard to remember.
> Every time when I read this position I wholeheartly agree with it;
> moreover, several times I tried it (at least partially) in practice,
> and in each case a reward was excellent... and nevertheless, I'm unable
> to keep it in mind and apply regularly. And I know well that I'm not
> alone with this strange kind of "disability". Why it is happened, and
> how one can "internalize this style of programming" (using your words) ?

The answer to that is easy.  When I sit down to write even a short 
program, I take out a piece of paper, or open Notepad, or whatever, and 
start doing requirements.  All it takes to internalize design to test is 
to recognize that even when you are doing a ten line example, THIS is 
faster, THIS is better, THIS is much more likely to be bug free, and 
THIS is much less stressful.  That time with the (real or virtual) 
notepad, often both, IS painful.  And a lot of stuff gets scribbled out 
as you realize that THIS IS A REQUIREMENT and you can't test it. But 
what you do end up with is a design where each component has an 
associated test, and that mapping eventually means that all sorts of if 
and case statements go away, or only get tested in one place.

Fortunately by now, when I don't do this, I stop after about twenty 
lines of code and go back and do it right. I'm too old to do things the 
hard way.

When I do this, I can knock out over a thousand lines of tested code a 
week.  (Not counting test programs, but counting some documentation.) 
Comparing my work with the sort of work done by government contractors, 
my block comment headers are much smaller, I use more whitespace, and I 
accomplish about ten times as much per line of code!  At first I thought 
this was crazy, then I took some existing code I hadn't examined, plus 
the requirements document--which I knew well--and rewrote a couple of 
units.  The big difference, and it was HUGE, was that I moved a lot of 
checking into the interfaces (including data types), while functional 
decomposition propagates it down into the leaves (subprograms).

> PS. After writing above words, one fantastic vision occured to me - I imagined
> Web-based master class - yours, "Programming using Ada". Why not? You have
> tremendous experience, rock solid skills and views, you are alive to hidden
> errors and potentially dangerous solutions, you are apparently willing to
> share your knowledge, and you don't like to write books and articles
> (I searched the Net and found only one your article, and it was on quite
> specific issue). This is extremely suitable combination for a master class
> instructor. Well, I understand that one more component is needed - there
> should be example problems, and it isn't a simple/pleasant task to collect
> good ones. But my vision included even this side - in the form of real-world
> examples from several first chapters of the book "Problem Frames: Analyzing
> and Structuring Software Development Problems" by Michael Jackson.

I have significant parts of the book written, some of it was presented 
as lectures around 1986.  However, I have been seriously disabled for a 
while now.  Right now I am up to using the computer (and up to thinking, 
which is more important), so I may be able to finish that book and a 
couple of others.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.