Theory and Practice [was: Beware of "C" Hackers -- A rebuttal to ...]
David Hoag
Kamal Hathi (kha...@ee.net) wrote:
: Software *Engineering* unfortunately is a gross misnomer. I am an
: Electrical Engineer by education (undergraduate) and also have
: training (post-graduate education and other) and experience as a
: "Software Engineer". One thing I can categorically state is that
: developing software and the education in that field is closer to
: art or language (as in english) than Engineering. Engineering is
: an *exact science*, with a certain degree of inexact creative
: license thrown in for good measure. Software Engineering is
: mostly a set of inexact and flexible *techniques* with some
: exactness thrown in.
Software is far from an exact science and is in many way an art.
However, I do believe that the basic problem solving skills that all
engineers develop readily apply to developing software.
: Software may be the "most complex man-made systems", however, the
: *science* of Software Engineering may also be the most non-scientific
: and inexact of all Engineering. Till this discipline matures (say 100
: years or so), it will continue to be a nascent science and a mature
: art.
In fact this is probably one of the biggest criticisms of software
today. To much of it is left up to the artistic whims of the
programmer. Little effort is spent to actually use a disciplined
approach to designing and developing software. There are many known
techniques that will produce high quality software, but yet very few
'software engineers' employ them.
Dave
--
David Hoag k
dh...@netcom.com
Patrick D. Logan
>Software *Engineering* unfortunately is a gross misnomer. I am an
>Electrical Engineer by education (undergraduate) and also have
>training (post-graduate education and other) and experience as a
>"Software Engineer". One thing I can categorically state is that
>developing software and the education in that field is closer to
>art or language (as in english) than Engineering. Engineering is
>an *exact science*, with a certain degree of inexact creative
>license thrown in for good measure. Software Engineering is
>mostly a set of inexact and flexible *techniques* with some
>exactness thrown in.
I have to disagree with this for many kinds of engineering work.
For example, from what I have observed as a software developer
who has spent most of his career in the EDA industry, designing
a new microprocessor or ASIC is like designing a new software
application *EXCEPT* the requirements are usually better understood
and the raw material is more of a constraint on the solution.
That is, in software applications the requirements are usually
more vague and broad and the raw material (i.e. source expressions
as opposed to transistors & gates, etc.) is more forgiving.
But software design *is* a kind of engineering. It is more complex
and less understood, but... oh, well, you'll either agree or disagree
so I'll stop here.
--
Patrick...@ccm.jf.intel.com
Intel/Personal Conferencing Division
(503) 264-9309, FAX: (503) 264-3375
Kamal Hathi
>> On 5 Jul 1995 03:44:13 -0400, Ebneter wrote
>>
>> > I'm an astronomy Ph.D. currently working in the commercial software
>> > industry (at Apple). I don't think my science background makes me any more
>> > or less competent as a programmer than any other self-taught programmer,
>>
>On Fri, 7 Jul 1995, Neil Gall wrote:
>> Perhaps not, but without proper training, you probably understand the
>> principles and theory of software engineering about as well as most of
>> us CS graduates understand astronomy.
>>
"Steven D. Majewski" <sd...@Virginia.EDU> wrote:
> Theoretical Physics is at the other pole. I'm not sure
>where Software Engineering would be, but I'm afraid its probably
>closer to juggling than to Physics - maybe just on the theoretical
>side of chess.
Software *Engineering* unfortunately is a gross misnomer. I am an
Electrical Engineer by education (undergraduate) and also have
training (post-graduate education and other) and experience as a
"Software Engineer". One thing I can categorically state is that
developing software and the education in that field is closer to
art or language (as in english) than Engineering. Engineering is
an *exact science*, with a certain degree of inexact creative
license thrown in for good measure. Software Engineering is
mostly a set of inexact and flexible *techniques* with some
exactness thrown in.
Software may be the "most complex man-made systems", however, the
*science* of Software Engineering may also be the most non-scientific
and inexact of all Engineering. Till this discipline matures (say 100
years or so), it will continue to be a nascent science and a mature
art.
Kamal Hathi
Alan Darlington
<snip>
> Electrical Engineer by education (undergraduate) and also have
> training (post-graduate education and other) and experience as a
> "Software Engineer". One thing I can categorically state is that
> developing software and the education in that field is closer to
> art or language (as in english) than Engineering. Engineering is
> an *exact science*, with a certain degree of inexact creative
> license thrown in for good measure. Software Engineering is
> mostly a set of inexact and flexible *techniques* with some
> exactness thrown in.
I believe that you can call engineering an exact science only
because most traditional engineers (mechanical, electrical, etc.)
are reusing work that has already been done, such as designing
the 1,000th interstate freeway bridge. The rough equivalent of
this in software engineering is copying a program from one
floppy to another to duplicate it... :-)
To see how traditional engineers do on leading edge projects,
consider the Alaskan pipeline (years late and a factor of 10
over budget), nuclear power plants, space shuttle, etc. These
are much more equivalent to the daily work of software
engineers, and tend to show the same lack of exactness. :-(
(I will concede that many software engineers are reinventing
the wheel, but this is a different story...)
-- Alan
Rick Hawkins
>Engineering is
>an *exact science*, with a certain degree of inexact creative
>license thrown in for good measure. Software Engineering is
>mostly a set of inexact and flexible *techniques* with some
>exactness thrown in.
I'd qualify that some more. engineering is not *a* scence itself, but
the *application* of science, usually physics.
--
R E HAWKINS
rhaw...@iastate.edu
--
R E HAWKINS
rhaw...@iastate.edu
Murray Davidson
"Patrick D. Logan" <patrick...@ccm.jf.intel.com> wrote:
>kha...@ee.net (Kamal Hathi) wrote:
>>Software *Engineering* unfortunately is a gross misnomer. I am an
>>Electrical Engineer by education (undergraduate) and also have
>>training (post-graduate education and other) and experience as a
>>"Software Engineer". One thing I can categorically state is that
>>developing software and the education in that field is closer to
>>art or language (as in english) than Engineering. Engineering is
>>an *exact science*, with a certain degree of inexact creative
>>license thrown in for good measure. Software Engineering is
>>mostly a set of inexact and flexible *techniques* with some
>>exactness thrown in.
>
>I have to disagree with this for many kinds of engineering work.
>
>For example, from what I have observed as a software developer
>who has spent most of his career in the EDA industry, designing
>a new microprocessor or ASIC is like designing a new software
>application *EXCEPT* the requirements are usually better understood
>and the raw material is more of a constraint on the solution.
>
>That is, in software applications the requirements are usually
>more vague and broad and the raw material (i.e. source expressions
>as opposed to transistors & gates, etc.) is more forgiving.
>
>But software design *is* a kind of engineering. It is more complex
>and less understood, but... oh, well, you'll either agree or disagree
>so I'll stop here.
I find statements about the exactitude of engineering (or of any other science,
for that matter) rather disturbing.
Many branches of engineering can be characterised (amongst others) as follows:
- they impose degrees of tolerance upon values (e.g. the diameter of
a tube shall be 20.0 +/- 0.01 mm);
- they have standard codes or rules for the calculation of behaviour
of materials or parts or structures (or etc...) which assume tolerances
are respected to a certain confidence level;
- designs (are supposed to) allow degradation rather than catastrophic
failure;
- the effect of overloading or incorrect application (analogous to invalid
usage in software) is failure to operate, degradation or non-catastrophic
failure;
- when mission critical products are concerned, quality control on as many
aspects as necessary to ensure the reliability figure (assessed against
particular identified failure modes) is imposed.
There is one difference of principle between manufactured engineering products
and software - when series production is involved, testing and QA are used to
filter out those combinations of components whose tolerances mismatch or which
simply out of spec.
The glaring difference with S/W engineering is that we rarely have "components".
Certainly, components do not exhibit tolerance ranges with confidence levels
in their quality since they are identical copies (there is no manufacturing run).
Even in one-off structures, there is always the concept of "margin" of
performance against environmental conditions or user application.
Even in the calculations performed to demonstrate margin (where testing is not
possible or is not economically reasonable), engineering remains inexact. The
results, based on certain hypotheses, will demonstrate a degree of margin in
performance (strength, lifetime, signal handling, bandwidth or whatever) that
is justified as adequate through sensitivity analysis (playing with the
dispersions of critical values).
The analogue which might be introduced for systems (programs) based on components
is of graceful degradation of performance in place of failure. This would require
a degree of fuzziness in specification - certainly, algorithmic specification of
functionality and performance do not admit of a close analogy with normal
engineering. A more component-centric view of software construction with ranges
of interface conditions being tolerated rather than hard or exact values would
then result. [A lot of this is probably more familiar to those working in
(distributed) simulations or distributed systems generally.]
In summary:
- real engineering is *fuzzy* and not exact;
- software needs a big shift in world view to become real engineering.
Murray
Murray Davidson European Space Agency Research and Technology Centre
mur...@yc.estec.esa.nl ESTEC, Postbox 299, 2200 AG Noordwijk, Netherlands
These are my thoughts and opinions, not ESTEC's.
Jimmy Nguyen
>Software *Engineering* unfortunately is a gross misnomer. I am an
>Electrical Engineer by education (undergraduate) and also have
>training (post-graduate education and other) and experience as a
>"Software Engineer". One thing I can categorically state is that
>developing software and the education in that field is closer to
>art or language (as in english) than Engineering. Engineering is
>an *exact science*, with a certain degree of inexact creative
>license thrown in for good measure. Software Engineering is
>mostly a set of inexact and flexible *techniques* with some
>exactness thrown in.
I have to disagree with the above expression. In my opinion,
"Engineering" specialties are practices based largely on the
Mathematic (including Logics.) Yet, most of Mathematic are
also based on observations, assumptions, and/or estimations
(i.e: Pi, infinity, infinite series, infinite set, discrete functions...)
Thus, Engineering is not what I would call 'exact science' -
'best guestimation', maybe.
Regards,
Jimmy Nguyen
Robert G. Plantz
<snip>
> Software *Engineering* unfortunately is a gross misnomer. I am an
> Electrical Engineer by education (undergraduate) and also have
> training (post-graduate education and other) and experience as a
> "Software Engineer". One thing I can categorically state is that
> developing software and the education in that field is closer to
> art or language (as in english) than Engineering. Engineering is
> an *exact science*, with a certain degree of inexact creative
> license thrown in for good measure. Software Engineering is
> mostly a set of inexact and flexible *techniques* with some
> exactness thrown in.
My undergraduate and graduate education is in EE. My post-doctoral
education is in neuro-physiology. Along the way I studied quite a
bit about digital systems. Now I am a "software engineer."
I think that traditional engineering ceases to be exact when the
math models no longer work, e.g., when things get non-linear. I
recall designing a sinusoidal motion table for my graduate
research that used a DC motor with lots of feedback. I ran Bode
plots, etc. for many hours, trying to get rid of the inherent
dead zone, while keeping the thing stable. Finally, I cranked
the loop gain all the way up and went through some sort of
nonlinear place, and the machine worked very nicely. Well,
perhaps with better tools, I could've done a more exact analysis.
The concept of "exactness" is, at best, a mathematical model.
Nothing in the "real world" is truly exact. I think the real
problem with trying to "engineer" software is that our mathematical
tools for analyzing it are very underdeveloped. But, we are still
very young, compared to the traditional engineering disciplines.
I am not an historian, but I suspect that the other engineering
fields were just as much "a set of inexact and flexible *techniques*
with some exactness thrown in" when they were as young as this new
area in which we find ourselves.
Bob
Brian D Hall
: In <3tkbd7$7...@nt.colmicrosys.com>, kha...@ee.net (Kamal Hathi) writes:
: >Software *Engineering* unfortunately is a gross misnomer. I am an
: >training (post-graduate education and other) and experience as a
: >"Software Engineer". One thing I can categorically state is that
: >developing software and the education in that field is closer to
: >art or language (as in english) than Engineering. Engineering is
: >an *exact science*, with a certain degree of inexact creative
: >license thrown in for good measure. Software Engineering is
: >mostly a set of inexact and flexible *techniques* with some
: >exactness thrown in.
: I have to disagree with the above expression. In my opinion,
: "Engineering" specialties are practices based largely on the
: Mathematic (including Logics.) Yet, most of Mathematic are
: also based on observations, assumptions, and/or estimations
: (i.e: Pi, infinity, infinite series, infinite set, discrete functions...)
: Thus, Engineering is not what I would call 'exact science' -
: 'best guestimation', maybe.
I think we need to define what an engineer is:
According to one definition in my dictionary, an engineer is someone who
can "arrange or bring about skillfully".
Physics and Mathematics are exact sciences, engineering is not. Engineers
simply use science to make something work, but also take other things into
consideration: manufacturability, cost, etc. A Physicist would simply say that
something is possible, an engineer would say that something is practical and
devise a way to do it with the materials that are available to them. They are
two different and distinct skill sets.
Brian
Robert G. Plantz
> Jimmy Nguyen (jim...@vnet.ibm.com) wrote:
<snip>
> : >"Software Engineer". One thing I can categorically state is that
> : >developing software and the education in that field is closer to
> : >art or language (as in english) than Engineering. Engineering is
> : >an *exact science*, with a certain degree of inexact creative
> : >license thrown in for good measure. Software Engineering is
> : >mostly a set of inexact and flexible *techniques* with some
> : >exactness thrown in.
<snip>
> I think we need to define what an engineer is:
>
> According to one definition in my dictionary, an engineer is someone who
> can "arrange or bring about skillfully".
>
> Physics and Mathematics are exact sciences, engineering is not. Engineers
> simply use science to make something work, but also take other things into
> consideration: manufacturability, cost, etc. A Physicist would simply
say that
> something is possible, an engineer would say that something is practical and
> devise a way to do it with the materials that are available to them.
They are
> two different and distinct skill sets.
Very well said. To give an example, when working as an electrical
engineer back in the 60's, I was given the task of designing a
transformer for a component in the Gemini guidance system. The
theory and guidelines were already well known. Unfortunately, the
result was a transformer that was too big and too heavy, although
somewhat "exact."
So, and this is what I call "engineering," I thought about the
assumptions made in the guidelines. An important one is to minimize
the resistence (i.e., loss) in the wire, which implies large, heavy
wire. Meanwhile, we needed to add resisters (additional size and
weight) to protect the rectifying diodes. I simply redesigned
my transformer with small wire, that had "built in" resistence.
As we know, it worked just fine.
The reason I call myself a "software engineer" is that I find
myself doing very similar things when designing software.
Bob Plantz
bgr...@ibm.net
>kha...@ee.net (Kamal Hathi) writes:
><snip>
>> Electrical Engineer by education (undergraduate) and also have
>> training (post-graduate education and other) and experience as a
>> developing software and the education in that field is closer to
>> art or language (as in english) than Engineering. Engineering is
>> an *exact science*, with a certain degree of inexact creative
>> license thrown in for good measure. Software Engineering is
>> mostly a set of inexact and flexible *techniques* with some
>> exactness thrown in.
><snip>
>
>because most traditional engineers (mechanical, electrical, etc.)
>are reusing work that has already been done, such as designing
>the 1,000th interstate freeway bridge. The rough equivalent of
>this in software engineering is copying a program from one
>floppy to another to duplicate it... :-)
>
>To see how traditional engineers do on leading edge projects,
>consider the Alaskan pipeline (years late and a factor of 10
>over budget), nuclear power plants, space shuttle, etc. These
>are much more equivalent to the daily work of software
>engineers, and tend to show the same lack of exactness. :-(
>
>(I will concede that many software engineers are reinventing
>the wheel, but this is a different story...)
>
> -- Alan
Theoretically, the development of binary based software is indeed an exact science.
Further, for any binary based problem there exists a set of one or more
equivalent "optimal" solutions. And lastly, an optimal solution can be arrived by
employing a simple assembly of nand or nor binary operations. Kamal should
take a few computer science classes (discrete mathematics, switching theory,
sequential machines, numerical analysis) and benefit from a more informed
opinion.
The exact science is there, without a doubt. It's the crystal ball methodologists
and the business-heads that cloud the vision.
Bryant Griffin
bgr...@ibm.net
bgri...@bnr.ca
"an idle mind at work" bg
Darin Johnson
>
> - software needs a big shift in world view to become real engineering.
Good points. I tend to think of the software development process as
creating a working usable prototype. Just one is needed most of the
time, since it can be duplicated. Software engineering, depending
upon who is doing it, is a formalization of the design process. Often
real world engineering is just that too (only one bridge of its type
needs building). Software engineering tries to put in place
procedures that will detect or correct failures and design flaws
before they happen.
Also, as is currently the case anyway, software engineering is really
not engineering, it's management. Therein lies much of the trouble,
engineers often know little about management and have a disdain for
it, and managers often know little about engineering and have a
disdain for that. There's plenty of cases where software engineering
works, but there's also cases where ad-hoc methods work have worked
better with a shorter process time; I think this means that the
management of the process by itself is not enough. The advantage of
real engineering is that you can always point to the book or work out
a formula to cut through the politics of the management process, but
you can't do that with software.
As far as the concept of reusable plug in components in software goes,
it's not all that analogous to other types of engineering, yet it's
presented that way by many pundits. A really generic plug in
component for software may be bulky and slow compared to the component
designed specifically for the task. Yet that's not the problem, since
you can always just interchange the custom component if you want. The
problem is that the problems with software design aren't with the
components. That's the easy part of the picture, the hard part is
making them work together in the same environment; an environment that
is changing, even after the initial product is done. The hard is the
design of the whole. And you have to worry about retrofitting major
changes later on (in real engineering, if you redesign a part so that
it no longer has the same specs, you have to rework many other
components or you don't have a product; with software, economics can
dictate that you change a component out of spec and jury rig it so
you still have a product).
The process of software isn't like designing a 1995 Ford Ranger,
it's like designing the whole Ranger line with yearly changes and
mods. It's not like designing an overpass, it's like designing an
entire freeway system taking into account evolving demographics and
a few earthquakes. Sure, version 1.0 of the LA freeway system may
have been engineered to spec with state of the art techniques and
procedures, but it would be considered extremely buggy and nearly
useless today, prone to catastrophic failure. I don't think software
is something that *can* be engineered in the same sense as other
engineering disciplines (just like you can't build a radio using the
techniques used to build cars). That's not to say we should abandon
software engineering, just that it should try to find it's own way.
--
Darin Johnson
djoh...@ucsd.edu
"Particle Man, Particle Man, doing the things a particle can"
Robert G. Plantz
djoh...@tartarus.ucsd.edu (Darin Johnson) wrote:
<snip>
> Also, as is currently the case anyway, software engineering is really
> not engineering, it's management. Therein lies much of the trouble,
> engineers often know little about management and have a disdain for
> it, and managers often know little about engineering and have a
> disdain for that. There's plenty of cases where software engineering
> works, but there's also cases where ad-hoc methods work have worked
> better with a shorter process time; I think this means that the
> management of the process by itself is not enough. The advantage of
> real engineering is that you can always point to the book or work out
> a formula to cut through the politics of the management process, but
> you can't do that with software.
I have a feeling that you have never worked on a large scale
engineering project. My experience goes back to working on the
horizon scanner for the Gemini spacecraft. We were designing on
the basis of components that were just becoming available. And
the designs themselves were new, not from textbooks. And,
believe me, there was no way to cut through the politics of
the management process. It was an extremely political situation.
I have also worked on some fairly large software projects. E.g.,
designing a CAT scanner, designing an automated shipping container
handling system.
Hardly any differences amongst these various project that I
could detect.
Bob Plantz
Steve Isaskon
writes:
>>> On 5 Jul 1995 03:44:13 -0400, Ebneter wrote
>>>
>>> > I'm an astronomy Ph.D. currently working in the commercial software
>>> > industry (at Apple). I don't think my science background makes me
any more
>>> > or less competent as a programmer than any other self-taught
programmer,
>>>
>
>>On Fri, 7 Jul 1995, Neil Gall wrote:
>>> Perhaps not, but without proper training, you probably understand the
>>> principles and theory of software engineering about as well as most of
>>> us CS graduates understand astronomy.
>>>
>
>"Steven D. Majewski" <sd...@Virginia.EDU> wrote:
>> Theoretical Physics is at the other pole. I'm not sure
>>where Software Engineering would be, but I'm afraid its probably
>>closer to juggling than to Physics - maybe just on the theoretical
>>side of chess.
>
>Electrical Engineer by education (undergraduate) and also have
>training (post-graduate education and other) and experience as a
>"Software Engineer". One thing I can categorically state is that
>developing software and the education in that field is closer to
>art or language (as in english) than Engineering. Engineering is
>an *exact science*, with a certain degree of inexact creative
>license thrown in for good measure. Software Engineering is
>mostly a set of inexact and flexible *techniques* with some
>exactness thrown in.
I am a software test engineer. My degree is in EE, focused on
hardware, and most of my software knowledge is self-taught. I work
with embedded systems, so this is a good combination.
I agree that software engineering lacks the exactness of many other
engineering disciplines, but it lacks some other essential
characteristics.
Engineers need to know enough about actually implementing things,
but their primary function is to *design* things. When was the
last time you actually saw a civil engineer pouring cement, or a
mechanical engineer running a machine tool? The mechanical
engineer will design a part or whatever, give it to a CAD guy to
draw, who then gives it to a machinist to actually build.
Software is totally different- I have never heard of a shop that
had different people doing design and coding. In some more mature
organizations the design phase is distinct and the design is
fairly detailed, but this is not commonly true. Starting in the
60's, hackers have achieved a high degree of respect and notoriety
because they were good at coding and generally making computers do
useful (or not) things. Today, many of the people who have the
title of software engineer spend almost all of their time coding
and almost none designing.
As software engineering matures as a discipline, the perception that
good coders (hackers) == good software engineers will go away. We may
even start seeing separate design and coding functions!
David Brabant (SNI)
>In fact this is probably one of the biggest criticisms of software
>today. To much of it is left up to the artistic whims of the
>programmer. Little effort is spent to actually use a disciplined
>approach to designing and developing software. There are many known
>techniques that will produce high quality software, but yet very few
>'software engineers' employ them.
Because, when you try to promote them, your beloved manager kicks your
asses and says things like :
"This is time to market"
"Our customers don't want clever designs. They want solutions and
products that work. Additionaly, they want them for yersterday and
at low cost. If they have problems with our programs, we will
sell them training/maintenance/..."
"Reusability is not profitable if you can't reuse your module more
than x times" (where x is a value between 5 and 10^6)
"We are at the 'kleenex' software era",
...
>Dave
>--
>David Hoag k
>dh...@netcom.com
David
----- Standards are great. Everyone should have one ! (Charles Moore) -----
David Brabant, | E-mail: David....@csl.sni.be
Siemens Nixdorf, | X-400: C=BE;A=RTT;P=SCN;O=SNI;OU1=LGG1;OU2=S1
Centre Software de Liège, | S=BRABANT;G=DAVID
2, rue des Fories, | URLs: www.sni.de www.csl.sni.be/~david
4020 Liège (BELGIUM) | Phone: +32 41 201 609 FAX: +32 41 201 642
Kevin Cline
>Electrical Engineer by education (undergraduate) and also have
>training (post-graduate education and other) and experience as a
>"Software Engineer". One thing I can categorically state is that
>developing software and the education in that field is closer to
>art or language (as in english) than Engineering. Engineering is
>an *exact science*, with a certain degree of inexact creative
>license thrown in for good measure.
Perhaps by "Engineering" Mr. Hathi means the repeated application
of known solutions: 20 Amp circuit breaker => 8 gauge wire, or
2 watts / cm2 power density => 3.5 fps air flow. How boring.
It is true the the programmers do not have to deal with the vast
complexity of the physical universe. But then neither do most
EE's. Programmers combine pre-existing software components with
custom components. The best know what to build and what to buy.
This does not seem to differ much from the design of digital circuit
boards.
Programming and EE are both creative arts. The practice of EE does
sometimes require an understanding of physics that is not necessary
for software engineering. But not every EE graduate actually has that
understanding. The rest work just like the average programmer: copy
something from somebody else and change it around until it sort-of
works. Or else find somebody who really knows and ask them what to
do.
The real difference is that the requirement to actually pass courses
in mathematical analysis scares a lot of people away from EE programs,
and weeds out a fair number of the rest, so the overall quality of the
graduates is higher. Also, most EE programs require their
students to actually build things that work to graduate.
If CS departments refused to grant degrees until students could
demonstrate that they were able to produce a working program of 2000
lines or so, ALL BY THEMSELVES, I think the perceived quality of CS
graduates would improve a lot. Years ago CMU changed began using
a practical exam for the final of the first-level CS course. Students
sat in front of a screen and given 2 or 3 hours to write 200
or 300 lines of working code. If the program wasn't working or close
to working, they had to retake the course. I don't know if this
practice continues today, but I hope it does.
--
Kevin Cline
Marshall Woodson
There is one important distinction between Engineering and software
development that seems to be missing from this discussion. In any
engineering project it is often impratical to build test articles,
or components to verify design decisions. This means that Engineers
must rely on analysis done during the design phase, to "get it right"
the first time. Limited testing is usually done afterwards, to verify
the analysis. Contrast this with software development which in
practice envolves little if any analysis, and a great deal of testing.
Many of the comments in the "hackers" thread suggest that in some
cases software developers give little thought to the design phase,
and simply start writing code. It is the requirement to produce
theoretical and analytical models of physical systems which tends
to separate engineering from other disciplines.
Regards,
Marshall
Tim Church
software validation. They mentioned a Dutch academic by the name of Dykstra,
who is a mathematician promoting mathematical proof of software validity
(yeah, I know about Godel, A.Church, etc.). Does anyone have a reference?
Tim Church
John Sellers
In Article<3u66as$5...@sun132.spd.dsccc.com>, <kcl...@sun132.spd.dsccc.com>
write:
> ///
> It is true the programmers do not have to deal with the vast
> complexity of the physical universe. ...
The real advantage that engineers who work with the "physical universe"
over programmers is that the operating system is better.
Imagine, no system crashes!
John Sellers
In Article<3uelai$6...@gazette.medtronic.COM>, <tim.c...@medtronic.com>
write:
> ...
> ...
Dykstra is a character to say the least. He makes his own ink so that his
writings won't fade. He came to the SF Bay area for a talk and I asked
him about Smalltalk. His exact words were: "I don't do that. That is
interactive."
Someone asking a technical question about an article in SIGPLAN notes and
he took out a note pad and wrote out a 5 page proof as fast as he could
write, never scratching out anything or hesitating.
0000-Admin(0000)
Kevin Cline <kcl...@sun132.spd.dsccc.com> wrote:
>In <3tkbd7$7...@nt.colmicrosys.com>, kha...@ee.net (Kamal Hathi) writes:
>>Software *Engineering* unfortunately is a gross misnomer. I am an
>>Electrical Engineer by education (undergraduate) and also have
>>training (post-graduate education and other) and experience as a
>>"Software Engineer". One thing I can categorically state is that
>>developing software and the education in that field is closer to
>>art or language (as in english) than Engineering.
Very, very true!
>If CS departments refused to grant degrees until students could
>demonstrate that they were able to produce a working program of 2000
>lines or so, ALL BY THEMSELVES, I think the perceived quality of CS
>graduates would improve a lot. Years ago CMU changed began using
>a practical exam for the final of the first-level CS course. Students
>sat in front of a screen and given 2 or 3 hours to write 200
>or 300 lines of working code. If the program wasn't working or close
>to working, they had to retake the course. I don't know if this
>practice continues today, but I hope it does.
In my experience, there are three type of programmers:
1) The Hacker -- self-taught, able to do anything, optimizes every
line of code to get the best performance, thinks "algorithm" is a
button on a calculator, never heard of a splay tree.
2) The Scholar -- went to school to learn, studied the science of
programming, knows the best algorithm for the job and why, thinks
optimization is what compilers do, passes 30k structures by value.
3) The Hacker who went to School -- the best of both (a _real_ catch if
you're recruiting for your company)
I remember being a #1 and wondering why taking CS courses was
necessary. I used to think that I needed my degree (Computer
Engineering, by the way) to _get_ a job, but not to _do_ my job. Boy,
was I wrong! My abilities jumped 2-fold, at least, when I learned
more advanced algorithms and programming styles. On the other hand,
I've worked with a guy with 6 degrees (BaSc: Pure Math, Elec Eng, Comp
Sci; Masters: EE, CS; PhD: CS) that couldn't write a decent program to
save his life.
Just my $0.02...
Brian
( bcw...@bnr.ca )
-------------------------------------------------------------------------------
In theory, theory and practice are the same. In practice, they're not.
Steve Tate
> tim.c...@medtronic.com (Tim Church) writes:
>>I caught the end of an item on NPR regarding the US vs European approach to
>>software validation. They mentioned a Dutch academic by the name of Dykstra,
>>who is a mathematician promoting mathematical proof of software validity
>>(yeah, I know about Godel, A.Church, etc.). Does anyone have a reference?
> EJ Djikstra - A Discipline of Programming, currently at Texas A&M
> I think.
Djikstra is actually at the University of Texas (in Austin).
--
Steve Tate --- s...@cs.unt.edu | "As often as a study is cultivated by narrow
Dept. of Computer Sciences | minds, they will draw from it narrow
University of North Texas | conclusions." -- John Stuart Mill, 1865.
Denton, TX 76201 |
James Delisle
>
>[Snip]
>>In fact this is probably one of the biggest criticisms of software
>>today. To much of it is left up to the artistic whims of the
>>programmer. Little effort is spent to actually use a disciplined
>>approach to designing and developing software. There are many known
>>techniques that will produce high quality software, but yet very few
>>'software engineers' employ them.
>
> Because, when you try to promote them, your beloved manager kicks your
> asses and says things like :
>
> "This is time to market"
> "Our customers don't want clever designs. They want solutions and
> products that work. Additionaly, they want them for yersterday and
> at low cost. If they have problems with our programs, we will
> sell them training/maintenance/..."
> "Reusability is not profitable if you can't reuse your module more
> than x times" (where x is a value between 5 and 10^6)
> "We are at the 'kleenex' software era",
> ...
>
>>Dave
>>--
>>David Hoag k
>>dh...@netcom.com
Tom Love, in a wonderful book entitled, "Object Lessons - Lessons
Learned in Object-Oriented Development Projects", addresses this
dichotomy in several different ways. He compares it to becoming a
master wood worker from an apprentiship that lasts for decades.
Even this small analogy holds a great deal of truth about becoming
a software "engineer." It takes a great deal of time, patience and
committment to foster an understanding of what this art/science is
all about. Hey, it's only been around for about forty years,
everyone's still learning as we go. One problem that we are dealing
with that the master artisans of the past didn't is the speed at
which our tools change. That in itself could keep this whole
ballywicke a jumbled mess for a long time to come.
FYI, the above mentioned book is available from:
SIGS Books
588 Broadway, Suite 604
NY,NY 10012
****************************************************************************
*jas. del'Isle * The TRUTH *
*orb...@well.com|lzk...@clc.gmeds.com is out *
******************************************************** There *
Jonathan Allan
[thunk]
|> programming, knows the best algorithm for the job and why, thinks
|> optimization is what compilers do, passes 30k structures by value.
Hehehehe! That's what 32 bit OSs, flat address spaces,
and 32Meg of memory are for; right?
Jonathan (What? Me worry? *8-) Allan
--
* Nobody except me has any stake in this opinion, and *
* if I'm playing Devils Advocate, even *I* don't. *
* Email to k...@mill2.millcomm.com won't bounce. *
Michael Feldman
Tim Church <tim.c...@medtronic.com> wrote:
>I caught the end of an item on NPR regarding the US vs European approach to
>software validation. They mentioned a Dutch academic by the name of Dykstra,
>who is a mathematician promoting mathematical proof of software validity
>(yeah, I know about Godel, A.Church, etc.). Does anyone have a reference?
>
author of the original letter to CACM in '68 (I think it was) which the editor
titled "Goto Statement Considered Harmful."
He also first posed the dining philosophers problem in '71, and was
very influential in the "structured programming" movement of the 60's
and 70's, though he thought his ideas were misapplied as a faddish
industry thing (sound familiar)?
He also had quite a bit to say about concurrency in the early 70's
(dining philosophers, etc.) and developed the THE (Technische Hogeschool
Eindhoven) operating system, an early PDP-11-based timesharing system.
He's been at the University of Texas for a number of years now.
He still favors a formal-methods approach to verification, as the
NPR series made clear.
Check his listings in the catalog at any decent technical library.
His more recent books should be in good technical bookstores.
That NPR series was a very good exposition of software, I thought.
Technically sound but written in terms regular folks could follow.
NPR should put out a cassette with those three segments.
That's an excellent example of why NPR should live and flourish.
Mike Feldman
Michael Feldman
Stephen J Parker <spa...@well.sf.ca.us> wrote:
>EJ Djikstra - A Discipline of Programming, currently at Texas A&M
>I think.
Well, I'm sure the Texas Aggies would just LOVE to claim him, but he's
actually at the University of Texas, Austin. Unless he's moved.:-)
Mike Feldman
Stephen J Parker
>I caught the end of an item on NPR regarding the US vs European approach to
>software validation. They mentioned a Dutch academic by the name of Dykstra,
>who is a mathematician promoting mathematical proof of software validity
>(yeah, I know about Godel, A.Church, etc.). Does anyone have a reference?
>Tim Church
EJ Djikstra - A Discipline of Programming, currently at Texas A&M
I think.
Other interesting reading in this area might be Cliff Jones book
on VDM and any of the material from the Oxford Programming Research
Group on Z (Michael Spivey etc.) I believe that Mario Wolzcko did
a spec for the ST class library in VDM some while ago - anyone from
Manchester know where to find it? There is also a formalism called
Fresco which is explicitly for Smalltalk. Z is currently being
formalised by X3J21 as a standard for specification. It would be
nice if X3J20 specced its work in Z ...
Steve
Mark Bergman
: There is one important distinction between Engineering and software
: Regards,
: Marshall
I studied some of the history of Engineering. Throughout antiquity, a new
engineering field was constantly being discovered through "trail and error."
The mature engineering disciplines have been built on hundreds, if not
thousands, of years of discovery, experimentation, failure, and eventually,
repeatable success. We have been "hacking" throughout time. It is a
natural phase of a young discipline.
I have also seen many engineers in mature fields (mechanical, electrical,
etc.) hack on their designs as well, esp. with the advent of CAD/CAM/CAE
tools. (Though, this could be considered the software-ization of
mature engineering fields.) Anyway, we are not alone in our "sin."
More importantly, we need to acknowledge that building software is not as
easy as we think it should be. We just do not understand the whole field
that well. Give it a few more years (maybe 50 to 100, hopefully less)
to mature.
I suspect much of our hacking comes from not knowing
what else to do in an ugly situation. And, some of it is just
plain laziness. I think we need to spend more time differentiating the
two, than condemning the whole practice. Maybe there is some knowledge
to be gained in studying when and why we hack. This could lead to
a better understanding of a class of problems in creating software and then,
the creation of a better set of techniques to deal with these problems.
Be patient with those who hack. Work to find out why it is happening. There
maybe more going on than you suspect. Show, where and when appropriate,
better ways of doing software engineering. Also, if you discover something
interesting, share it with us. This is how we can evolve software engineering
into a more mature engineering discipline.
Mark Bergman
--
############################## E Pluribus Unix ################################
Mark Bergman mber...@netcom.com
"Ping-ponging across america on a quest for knowledge..."
"Think Globally, Eat Locally"
R.L.Zijlstra
>Stephen J Parker (spa...@well.sf.ca.us) wrote:
>> tim.c...@medtronic.com (Tim Church) writes:
>>>I caught the end of an item on NPR regarding the US vs European approach to
>>>software validation. They mentioned a Dutch academic by the name of Dykstra,
>>>who is a mathematician promoting mathematical proof of software validity
>>>(yeah, I know about Godel, A.Church, etc.). Does anyone have a reference?
>> EJ Djikstra - A Discipline of Programming, currently at Texas A&M
>> I think.
>Djikstra is actually at the University of Texas (in Austin).
Let's Keep spelling correct:
E.J. Dijkstra
Michael O'Hair
>
>In fact this is probably one of the biggest criticisms of software
>today. To much of it is left up to the artistic whims of the
>programmer. Little effort is spent to actually use a disciplined
>approach to designing and developing software. There are many known
>techniques that will produce high quality software, but yet very few
>'software engineers' employ them.
One of the problems that I have seen repeatedly is that management does not
understand software. Throw in a handful of unrealistic schedules, take away
adequate resources, simmer for a long time, and suddenly you have a Dilbert
strip. I've seen more than one company brought down by management following
their resident prima donna down the garden path.
My personal opinion is that progress is made at the point of a sharp stick and
the industry will not change until it has to. The pivotal event, in my personal
opinion, will be a multi-billion dollar lawsuit where some major development
house goes down because of bad software engineering practices.
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
~ ~
~ The standard disclaimers apply. ~
~ ~
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Jonathan Allan
|> In article <3ue75o$n...@reznor.larc.nasa.gov>,
|> Marshall Woodson <M.B.W...@larc.nasa.gov> wrote:
|> >[...]It is the requirement to produce
|> >to separate engineering from other disciplines.
|>
|> _Analog_, I came to two startling conclusions:
|>
|> 1) There is no such thing as software engineering. There is only applied
|> software design science. 50% of what should be the engineering practise
|> (practical knowledge of the basic properties of the medium being engineered)
|> became denigrated as hacking over the last decade or so.
|>
|> 2) The reason that there is no software engineering is that engineering
|> itself is tending towards being applied science, with the computer ironically
|> bolstering that trend.
|>
|> Imagine an structural engineer trying to engineer (NOT design!) a bridge who
|> didn't know the structural properties of the metals being used (because that
|> was all low level detail). In fact, this 'engineer' has never even seen a
|> bridge or built one (but perhaps had built some models, but maybe only on
|> a computer simulator -- maybe). Is this person properly described as an
|> engineer? (Or an applied scientist, or designer, or what?)
This is really a good argument for an apprenticeship
program like is used to become a Professional
Engineer. Take a rigorous exam and then go practice
under the tutelage of a practicing professional in
a mentor/student style relationship. At the rate
the software profession is changing, this idea has
several drawbacks however...
|> Now imagine a software 'engineer' who cannot describe the basic execution
|> properties of the machine code their compiler is producing. In fact, has
|> never had any expereince using machine code and knows very little about how
|> their assembler and linker/loader works, and scoffs at anyone who concerns
|> themselves with such details. Is cultured (and conventially promoted)
|> ignorance of the basics of the craft consistent with engineering practise?
Oh! Hot button alert! YES!!!!!! I agree.
But I also wonder how many *good* engineers are working
in thier field today who have never refined any steel,
or made thier own chips, or mixed thier own concrete.
I suspect there are many who understand intuitively the
properties of the materials they are spec'ing, even if
they have never put thier hands into air-entrained
concrete, or smelted ire ore in thier back yards, or
worked in a chip foundry...
Jonathan Allan
Rob Broadhead
> ...lots of stuff deleted about hackers and designers should work >together...
Actually the whole idea of object oriented is that the designers properly
design a system. Properly design meaning that each piece is properly
encapsulated and its interface is properly designed so that all you need
to know to implement it is the spec for that object. The designers then
hand off the design to a "hacker" that implements that piece in the
fastest and most efficient way. Of course each group will see themselves
as the critical group in creating the project and suffer from the grass
is always greener disease of "anybody can write code" or "anybody can
design a product." So, yes a company needs both designers and hackers,
but they don't need to work together if they do the job they are supposed
to. Granted I don't know of anybody who is skilled enough to write out a
design and have everybody who reads that design understand the author's
intention. Back to the point...a designer is probably going to be aided
by knowledge of how a system works, but if designing a system requires
the designer to understand the machine language of the system being
designed then it is a faulty design. There are some designs that are
impossible to implement, but the restraining factor tends to be things
like implementation language or environment. The bridge designer just
wants to see a bridge built I don't think they are going to demand that
it be built out of tin and they construction crew can only use tools that
are available at the local hardware store.
---Rob
Michael Furman
> ................. removed ...................
>1) There is no such thing as software engineering. There is only applied
>software design science. 50% of what should be the engineering practise
>(practical knowledge of the basic properties of the medium being engineered)
>became denigrated as hacking over the last decade or so.
>
>2) The reason that there is no software engineering is that engineering
>itself is tending towards being applied science, with the computer ironically
>bolstering that trend.
>
>Imagine an structural engineer trying to engineer (NOT design!) a bridge who
>didn't know the structural properties of the metals being used (because that
>was all low level detail). In fact, this 'engineer' has never even seen a
>bridge or built one (but perhaps had built some models, but maybe only on
>a computer simulator -- maybe). Is this person properly described as an
>engineer? (Or an applied scientist, or designer, or what?)
What is about atomic or subatomic structure of that metal? Must he know about that
like nuclear phisicist? I do not think so (at least in general case - if it is
a bridge and not a nuclear device)!
I do not think that engineer mast know ALL low level details - only relevant
detailes up to some level (for good enfineer - may be more). For example he can
use some mathematical facts without proof is he "trust" them.
About software engineer - (IMO) he does not nesessary have to know all details
about machine code if he use some language and compiler he trust. But knowing that
is always a plus. And some experience in low level programming, I am sure, is
nesesarry.
> .........................................................
>Brad Shapcott
>
>P.S. This is not really a retort to Marshall's point, but heck, I gotta hit
>the F key somewhere.
--
----------------------------------------------------------------------------------
--
Michael Furman, (603)893-1109
Geophisical Survey Systems, Inc. fax:(603)889-3984
13 Klein Drive - P.O. Box 97 en...@gssi.mv.com
North Salem, NH 03073-0097 71543...@compuserve.com
----------------------------------------------------------------------------------
--