Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!mcvax!unido!ecrcvax!periklis
From: periklis@ecrcvax.UUCP (Periklis Tsahageas)
Newsgroups: comp.software-eng
Subject: Re: software engineers
Summary: Computer science curricula DO NOT ignore debugging
Keywords: debugging, testing, software engineers
Message-ID: <720@ecrcvax.UUCP>
Date: 11 May 89 09:17:52 GMT
References: <854@odyssey.ATT.COM>
Reply-To: periklis@ecrcvax.UUCP (Periklis Tsahageas)
Organization: ECRC, Munich 81, West Germany
Lines: 65

In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes:
>Real programmers spend 90% of their time debugging.  Computer science
>curricula ignore debugging, perhaps because it can never be reduced
>to a theory.

In article <42fba1e1.183dc@apollo.COM> perry@apollo.COM (Jim Perry) writes:
>Unfortunately I believe real debugging skills can only acquired with
>experience.

I find it hard to believe that there exists a single Computer Science
(or Software Engineering for that matter) curriculum that ignores debugging.

I will use the term debugging as the process of :
1. Testing a [piece | system] of software
2. Identifying parts of its behaviour which [are not in | differ from] its specs
3. Identifying the changes that have to be made in the code
	(or, in the unfortunate case, in the specification) and
4. Doing these changes.

In the first year of our Software Engineering degree, in the programming course,
we had a series of lectures on testing.  Some theoretical foundations for
testing were laid then.  Examples I recall AND USE :
I. Test harnesses (e.g. to test ADTs, write a simple menu-driven program which
performs operations on objects of the ADT and displays the results)
II. Test stubs (e.g. to test a complex program, write dummy versions of the
procedures it calls (and ADTs it uses) and test it with them)
It's obvious that the above correspond to bottom-up and top-down design.
There is no reason, however, that they can not be combined.

Task 2 does not seem trivial but, again, I will argue that there are
theoretical foundations here as well.  Consider, for argument's sake, the
testing of a procedure which performs some manipulation on lists.  Its spec
will have been written based on the definition of a list (well known, I
presume, to all programmers and S.E.s reading this :-)).  It follows that the
test cases tried using (I) will include at least one empty and some non-empty
lists.  The differences between specs and functionality of the implementation
will, thus, be easily located.

For task 3 you are not on your own : complete specifications, written by an
appropriate method, careful, modular, DOCUMENTED design (and experience) will be
your best friends.  Note that this is a task equivalent to coding.  Assuming,
however, that a good design will, probably, mirror the specs, it shouldn't be
difficult to pinpoint the erroneous parts of the code.
According to taste, you might want to use a debugging tool.  Personnaly, I think
that debuggers are usefull only for discovering bugs in other people's code.
Our college's curriculum didn't ignore this subject either.  In the second year,
the theoretical foundations were laid for writting specifications and design.
During the whole degree, programming exercises cover a broad range of languages,
compilers, operating systems and computers.  I would find it highly unlikely for
someone to tackle these (especially the first ones) without making any errors.

As for task 4,
as nick@hp-sdd.hp.com.UUCP (Nick Flor) put it, in article <1985@hp-sdd.hp.com> :
>Real programmers use only one CASE tool: vi.
Real software engineers, however, wouldn't dream of starting a project without,
at least, something with the functionality of [SC|R]CS.

A final note, just to stir things up :
SOME programmers have a very clever way of reducing the time spent debugging :
They don't write specs :-).  This makes task 2 trivial !
-- 
Periklis Andreas Tsahageas           European Computer-Industry Research Centre
Arabellastrasse 17, D-8000 Muenchen 81, West Germany       +49 (89) 92 69 91 09
USA: periklis%ecrcvax.uucp@pyramid.pyramid.com     ...!pyramid!ecrcvax!periklis
Europe: periklis@ecrcvax.uucp                        ...!unido!ecrcvax!periklis