Sam Trenholme's webpage
This article was posted to the Usenet group alt.hackers in 1995; any technical information is probably outdated.

Re: Hacker FAQ (please comment and help fix)


Article: 7682 of alt.hackers
Newsgroups: alt.hackers
From: grobson@netcom.com (Gary D. Robson)
Subject: Re: Hacker FAQ (please comment and help fix)
Message-ID: grobsonD79r6L.I1o@netcom.com
Followup-To: alt.hackers
Organization: what a novel concept!
X-Newsreader: TIN [version 1.2 PL1]
Date: Wed, 19 Apr 1995 06:25:33 GMT
Approved: sure.  why not?
Lines: 49
Sender: grobson@netcom7.netcom.com
Status: RO

Heikki Levanto (heikki@lsd.ping.dk) wrote:
: Considering myself somewhat of the hackish nature, let me
: share here a hackish solution to the boring testing phase.
: May it serve as the ObHack for this post.

: 1) generalise it enough to make it interesting
: 2) Let the machine do the hard work

   I agree wholeheartedly.  I also agree with your feeling that properly
testing your code is a part of being a programmer, and anybody who uses
the "I'm a creative hacker, hence I'm above such drudgery"
excuse doesn't
deserve the title.

   When I was an operating systems programmer in the late 70's, the
company I worked for was preparing to release a major revision to our
system.  I had rewritten about 70% of the operating system, and the rest
of the team had made dramatic, sweeping changes to the application code
(it was a dedicated CAD system for chip design).  The system entailed
about 500,000 lines of assembly code for a processor similar to the Data
General Eclipse.  The boss and the application programmers declared the
system ready to ship.  I, and one of the "programmers-at-large"
in the
organization, vehemently protested.  We were told that bug reports had
dropped off to just about nothing.

   The company had an organized test group with automated procedures that
literally ran for days, checking integrity of the code.  The problem was
that it checked the code with known data!

   The other programmer and I spent the night at the office, beating on
the system.  Anywhere that the manual said to press a comma, we'd press a
colon (or a space, or an "A").  We aborted process in mid-stream.  We
used bad arguments to commands.  We performed area calculations on lines
with zero width.  When the boss came in at 9:00 the next morning, we
handed him *five hundred* bug reports.

   The release was stopped, and I think we shipped a far better product
because of it.  The moral to the story (heck, shall we just call my story
an ObHack, too?) is that a good hacker needs to understand what testing
is all about, and needs to be able to test the code he or she (or
his or her co-workers) writes!  Testing ain't just boring drudge work.
In fact, we made a game out of it.  When a programmer declared a major
piece of code ready to go, the other programmers were given "open
season"
for a day, with free drinks for whoever found the most problems in it.

--
 /---------------------------- Gary Robson ----------------------------\
 |   Internet: grobson@netcom.com | "If it ain't broke, fix it anyway. |
 | CompuServe: 76130,1111         |  How else can you truly learn it?" |
 \---------------------------------------------------------------------/



Parent Parent gone Parent

Back to index