Path: utzoo!attcan!uunet!samsung!usc!rutgers!att!cbnewsd!jhan
From: jhan@cbnewsd.ATT.COM (james.e.hanlon)
Newsgroups: comp.software-eng
Subject: Re: CS education [engineering, mathematics, and computer science]
Summary: Software Eng: Unique aspects
Message-ID: <3211@cbnewsd.ATT.COM>
Date: 19 Nov 89 21:34:13 GMT
References: <1408@cs.rit.edu>
Organization: AT&T Bell Laboratories
Lines: 89

In article <1408@cs.rit.edu>, mjl@cs.rit.edu writes:
> science/software engineering is its mode of inquiry.  I won't discuss

> mathematics and computing.  In this respect, a good dose of discrete
> mathematics or basic modern algebra is appropriate, not so much because
 
> 	Formal methods of software engineering require the engineer
> 	to think like a mathematician.  This is untrue of any other
> 	engineering discipline I am aware of.  Why the discrepancy?
> 	Can we address this by creating "boilerplate" mathematics
> 	for software engineering?
> 
> Mike Lutz
 
Mike Lutz has stated eloquently what has been on my  mind for a long time now,
as I have struggled to get my arms around a very complex, abstract, subject:
just what constitutes Software Engineering, and how should we best prepare
ourselves to go about doing it ?  I've concluded that S.E. should be
subdivided into three areas, all concerned with Discrete Logic Systems: their
Description, their Analysis, and their Construction. Conventional educational
practice fails us because it
	
	1. is not systematic, being component-oriented rather than
	   systems-oriented;

	2. offers little or no guidance regarding systems description tools,
	   techniques, goals, or philosophies;

	3. concentrates on analysis of only the historically numerical aspects
	   of software, that of algorithms; and

	4. persists in casting most solutions to problems in terms of linear,
	   sequentially oriented, languages, which have obscure syntax and
	   nonobvious side-effects.

For its part, Industry administers the second of the one-two punch
combination, by making formal policy statements that it will only hire
individuals who have thrived under such a restricted intellectual regimen.

It seems to me that most problems with software are Big Picture problems, and
that they could be sidestepped by workers with a Formal Systems Architecture
approach. With such talent at hand, problems like "How should I best track
field problem reports, and map them into my SCCS?" are replaced by "Aha, I see
that the multi-site architecture risks some update anomalies. I suggest
timestamping our transactions with a periodically resynchronized local
time-of-day clock to avoid them." 

I'm not sure that all mathematicians adopt the perspective implied above
when going about their daily work; but several mathematical "modes of inquiry"
definitely occur in software engineering. 

Learning these can be difficult in itself, but the first hurdle, finding out
just what modes are appropriate, presents an even greater immediate problem.
Apart from a grounding in the basics of sets and graphs that one gets in
Discrete Structures courses, I have personally found very helpful: Queueing
Theory, Operations Research, classical Formal Logic, Type Theory, the
philosophical origins of Set Theory, and certain areas of Formal Semantics
( note: some of these topics are not on any CS/SE curriculum; they're easy
enough to find books on in the library, though). An odd, but, in abstract
areas like Software, common, subject is the Epistemology of Personal Belief
Systems; tough to find courses on, but  accessible through "popular"
logicians like Smullyan. After becoming aware--later familiar--with the array
of supporting material available to the software engineer from other fields,
you will occasionally be gratified by moments of real communication with those
in other areas of your organization. They frequently have studied classic
problems that have SE implications, but under different names.


    Supporting Personal Anecdote

    I was trying to convince a VP Engineering that some subset of field
    problems derived from the software engineers' failure to make the program's
    task scheduling algorithm explicit. As I went on about processes and
    ports, and memory allocation, and time slices, all being finite, etc., he
    interrupted with "It's just Bin Packing". Which is how he had learned 
    scheduling theory--I had learned Operating Systems.

To return to the original poster's point, I think that, in some ways, there is
a "boilerplate" solution to the Software Engineer's problems--it's just
that the necessary patterns of thought and expression involve what are
presently considered impossibly esoteric subject areas. Does the Engineer have
to be Philosopher, Epistemologist, Logician, Semanticist ? Perhaps not
literally; but such fields do provide intellectual support for a more distant
systems perspective. I have seen too many projects, and too many engineers,
wallow in minutiae, to dismiss such notions out of hand.

Comments, anyone ?

Jim Hanlon				AT&T-BL