Browse Prior Art Database

The Zero Law of Debugging of Structured Programming -- How Far Structured? Disclosure Number: IPCOM000131349D
Original Publication Date: 1978-Aug-01
Included in the Prior Art Database: 2005-Nov-10
Document File: 3 page(s) / 18K

Publishing Venue

Software Patent Institute

Related People

True Seaborn: AUTHOR [+3]


G. Samid

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3


This record contains textual material that is copyright ©; 1978 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Contact the IEEE Computer Society (714-821-8380) for copies of the complete work that was the source of this textual material and for all use beyond that as a record from the SPI Database.

The Zero Law of Debugging of Structured Programming -- How Far Structured?

G. Samid

The Open Channel

The Open Channel is exactly what the name implies: a forum for the free exchange of technical ideas. Try to hold your contributions to one page maximum in the final magazine format (about 1000 words).

We'll accept anything (short of libel or obscenity) so long as it's submitted by a member of the Computer Society. If it's really bizarre we may require you to get another member to cosponsor your item.

Bend everything to Jim Haynes, Applied Sciences, UC Santa Cruz, CA 95064.

The amazing statistics showing new "peaks" in debugging to coding effort ratios have already yielded several so-called "Laws of Debugging,"i all aimed at the ultimate goal of "quickas- possible" debugging. On the other hand, formal approaches -- program verification and proofs2 3 -- have been developed, which bear the idea of a clean, bug-free design.

Let's state an alternative approach. so trivial that it should be called "The Zero Law of Debugging." which states:

Don't debug! Recode!

In order to assign some meaning to this strange statement, please direct your attention to the paragraphs below.

If for just one moment we programmers would lift our heads from our never ending coding sheets and loot at the hardware environment around us. we would see how an electrician takes care of his system. After locating the wrong circuit-card or whatever unit, does he debug it? Does he try to pin-point the exact failure? We would probably find him replacing the entire unit with a new, tested one.

What do we do with a malfunction in our dear television set? We probably "debug" it (or pay to somebody to do it). But what do we do with our malfunctioning pocket transistor radio? We probably replace it.

So let's draw the conclusion from this that for small enough units. the replacement approach proves itself economical.

And here we come back to our professional environment -- if we could locate malfunctions in, a small enough module in our software. and if we were stubborn enough to maintain a strict structuring of our system down to the level of that module, then recoding that module could be less cumbersome than debugging it. This suggestion gains weight if the module was programmed by someone else. or had insufficient 'comments" or "remarks" in the code. m was coded in an unfamiliar language.

IEEE Computer Society, Aug 01, 1978 Page 1 IEEE Computer Volume 11 Number 8, Page 77

Page 2 of 3

The Zero Law of Debugging of Structured Programming -- How Far Structure...