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
----------------------------------------------------------------------------------
--
Brad Shapcott
Jonathan Allan <k...@mill2.millcomm.com> wrote:
>[...]
>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...
Exactly one of Stine's point, although he refers to this as 'bending tin',
and relates how too often he finds CAD experts where there should be engineers.
Another pointed parallel between Stine's engineers and software engineers is
that design is often motivated more by fear of failure than by anything else,
as if it could be practical or cost effective to achieve zero defect rates
by design alone. (The usual bit of logic is to demonstrate how much cheaper
it is to repair a defect at design than later during the development cycle,
without attention to the specific types of error which are easy to eliminate
during design -- i.e. this overgeneralizes because there are classes of errors
that it is difficult to prevent during design without expending more time and
energy than letting them be sieved out during prototyping or testing). The
practical suggestion seems to be that prototypes have a larger role than
merely cementing software requirements, and proof of concept work (NOT
testing) should play a larger role in software development (and engineering
in general, Stine is saying).
>Jonathan Allan
Thanks to Jonathon for the additional points.
Brad Shapcott
Brad Shapcott
Orpheus <ti...@Starbase.NeoSoft.COM> wrote:
>
>>After reading an guest editorial by G Harry Stine in the June 1995 edition of
>>_Analog_, I came to two startling conclusions:
>
They claim science fiction and science fact, and certainly seem to deliver
on both (though the ratio is towards the former). I'd copy the article here
except for copyright, and summarize it except for fear of doing Stine some
injustice.
>Well, clearly, this is an argument about "definitions." I would
>argue that "Software Engineering"
>[...]
>Engineering is "the application of mathematical and scientific
>principles to practical ends, as the design, construction, and
>operation of economical and efficient structures, equipment,
>and systems."
Stine tells a story about (some German rocket scientist; embarrassingly, I
can't recall which) whose early experience was as a lab assistant, whose
early tasks would include filing (by hand) a round piece of metal into a
perfect cube. The traditional training of an engineer was hands-on (so Stine
claims -- my degree is in mathematics and computer science) and the
intuitive understanding gained by such labours proved invaluable foundation
for their work.
'Hacking' can be a perjorative term for the computing equivalent of filing
round chunks of metal into perfect cubes . . . by hand.
Now, co-incidentally, I was talking to an old friend and planner/architect
(cities and buildings) who was pinning this as broadly a problem, from
professionals to teachers (he mentioned specifically a geography teacher he
knew who had never travelled outside of the province in which he had been
born -- my friend was astounded being a native Englishman, speaking several
different languages and being well travelled, that book learning should
qualify anyone in that field without practical experience).
To bring this down to a personal level, I've found that my early experience
with computers in which I mostly 'hacked around' and explored the machine and
dabbled (a sort of technical dilettantetism (sp?)) has continued to be of
great value to me combined with a formal education. Abstraction without
pragmatic knowledge at least weakens, if it does not handicap, an ability
to engineer. (I have anecdotes, but I don't want to bore people.)
I'm sure we've also all had to bear the neophyte who launches immediately
into grandiose design schemes without concern for any of the practical
problems of implementation. It can be easy to design large, complex
systems because the problems of implementation are concealed under the
abstractions (I often joke that at a certain level its all boxes connected
by lines and at a certain level all it requires is a relabelling to determine
whether you've just designed software for a network router, an apartment
complex, or a new circuit board -- but that is a joke).
Improper abstractions are the bane of software design (arbitrarily assuming
reduction or simplification where it cannot be achieved, poor structure,
oversimplification to avoid managing complexity, und so weiter). People
with little practical training are too often guilty of this, and some even
become wholly absorbed in the design abstractions and the metaphors. And
those boxes are never as independent as their representation in design
suggests (the reason why one can't make a truly random number generator
on a VN machine).
>I don't understand the distinction. Design is part of engineering.
>What do you mean?
Exactly that! _Part_ of engineering. (Stine's point too, if I interpret
him correctly). Not the sum of it.
>A Software Engineer is not necessarilly working with A COMPILER. It
>could be MANY compilers or none. In computing, we have very important
>concepts of "portability" and "interoperability." We also have
>the idea of "levels of abstraction"--VERY IMPORTANT to allow the
>construction of complex software.
In fact, my experience has been that pragmatic knowledge is useful even there,
since coding for portability has often meant understanding the common features
and limitations of the target machines. This idea of abstraction and division
of labour is of course quite common in other fields, which have the benefit
of longevity establishing conventional roles (architect, carpenter and
plumber, for instance). I suspect that software engineering suffers a good
deal from an inability to definitely pinpoint the optimal point for fracturing
the field into 'levels of abstraction'. And it just doesn't have the con-
ventions of age, nor do analogies with other fields longer established wholly
help. And levels of abstractions are seldom clean. Typically both the
architect and carpenter are familiar with the properties of woods, although
their experience of the medium and application of the knowledge is different.
>I don't feel that good engineering is practiced in computing. That
>doesn't mean Software Engineering doesn't exist.
I didn't mean to say it couldn't exist, but that it isn't practised as
sound engineering. I'll admit to making the title and theme of the post
deliberatively provocative. Which is too say my point is really what you
say above, except posting from comp.object obliges me to be hyperbolic
in my claims ;-).
However, as a minor point I do suggest some conceptual care with the term
software engineering, since as a fledgling practise I think the roles and
responsibilities that emerge out of levels of abstraction are not yet
perfectly understood, and that perhaps software engineering becomes a bit
leading as terminology (why not software mechanics, software construction,
software crafting, and so on?). Not just as semantic piffle, but because
of the reasons Wittgenstein would give (having been mentioned here before)
or Eddington or Russell, about language shaping our thinking and vice versa.
(Or Quine, come to think of him.)
>I would say that, while OO technologies and techniques have solved
>some problems, they have uncovered others. Too much hype has made
>"OO" look bad in some ways.
Thanks for the excellent points, and as a blanket qualifier I offer all of the
above as my own opinion. If you can get your hands on Stine's articles I do
recommend them: they are informative and to the point.
>-t
How many software engineers are really software philosophers, software
semioticians, software artisans, software mechanics, or what not?
Brad Shapcott
Brad Shapcott
Marshall Woodson <M.B.W...@larc.nasa.gov> wrote:
>[...]It is the requirement to produce
>theoretical and analytical models of physical systems which tends
>to separate engineering from other disciplines.
After reading an guest editorial by G Harry Stine in the June 1995 edition of
_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?)
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?
(Also check out Stine's December 1992 piece in _Analog_. And if anyone is
having trouble with the source, I point out i) source arguments are always
tangential, and b) NASA saw fit to re-print Stine's first article and the
second was formulated out of testimony to a congressional committee).
Quite literally, people are discouraged from obtaining a practical knowledge
of computing that needs to be *supplemented* -- but not replaced -- by a
knowledge of theory (people who know machine codes for Motorola processors
by heart but can't tell you what is wrong with a bubble sort are a liability)
and design (again, people who think working components equal working system are
a liability). An engineer or team of engineers needs be well rounded and
firmly grounded to bring a project home (to SPEC and on BUDGET! [dammit]).
Frankly, the approach to object oriented technologies has done more to
exacerbate this problem, because too much emphasis is placed on design.
This may partially be the direction in which the pendulum has swung from
early days when too little attention was paid design, and partially because
in the early days of object technologies it was valuable to gloss over the
chief liability (performance) as inconsequential and overrated by [err, umm]
hackers. (Many real world applications are dominated by their execution
constants rather than number of iterations/recursions.)
Since I'm not about to invest overmuch time in a thread I am already finding
wearying, I'll sum the point as being that Meyer is playing two forces in the
creation of software against each other which out to be brought into harmony.
To tie in with other elements of this thread, it appears that theoretical
physicists seem to get pretty wacky too unless people with lab coats step in
every so often (I recall Douglas Hoefstaedter claiming that he gave up
quantum physics after reading a paper that postulated some 130 new
fundamental particles out of the mathematics -- when little experimental
evidence existed for far too many quantum-postulated particles already).
So hackers balk at the object oriented approach to SE for much the same reason
a structural engineer reject bridge design that disregards the tensile and
load bearing properties of building materials. Meyer's point resolves to
little more broadly than a thinly veiled ad hominem -- if there is an argument
against OO and unwillingness to accept its paradigms, the rebuttal lies in the
character of those in dissent.
[Many hackers also exhibit weaknesses, and please don't mistake this post
as a universal and blanket defense of hackers and hacking. Attacking hackers
has become something of a cheap, conventionalized trope which is easy and
safe, OTOH, and needs be questioned.]
Orpheus
>In article <3ue75o$n...@reznor.larc.nasa.gov>,
>Marshall Woodson <M.B.W...@larc.nasa.gov> wrote:
>>[...]It is the requirement to produce
>>theoretical and analytical models of physical systems which tends
>>to separate engineering from other disciplines.
"tends"?
>After reading an guest editorial by G Harry Stine in the June 1995 edition of
>_Analog_, I came to two startling conclusions:
[Haven't read this editorial. _Anolog_ is a science fiction mag, isn't it?]
>1) There is no such thing as software engineering. There is only applied
>software design science. [...]
>
>2) The reason that there is no software engineering is that engineering
>itself is tending towards being applied science, [...]
Well, clearly, this is an argument about "definitions." I would
argue that "Software Engineering"
1) is distinguished from "Computer Science" (but there is
significant overlap).
2) focusses on the "Life Cycle" of software, not the execution
of a particular program.
3) covers aspects such as:
i) project management
ii) testing
iii) analysis
iv) design
v) implementation
vi) methods
vii) tools
viii) practices (such as configuration management)
Engineering is "the application of mathematical and scientific
principles to practical ends, as the design, construction, and
operation of economical and efficient structures, equipment,
and systems."
>Imagine an structural engineer trying to engineer (NOT design!) a bridge [...]
I don't understand the distinction. Design is part of engineering.
What do you mean?
>didn't know the structural properties of the metals being used (because it
>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 seems like a contrived example. If the engineer is only concerned
about how the bridge will affect traffic flow, why would he care
about the structurla properties? There is such a thing as division
of labor. "Engineers" (regardless of their own personal opinions)
are not gods.
>Now imagine a software 'engineer' who cannot describe the basic execution
>properties of the machine code their compiler is producing.
A Software Engineer is not necessarilly working with A COMPILER. It
could be MANY compilers or none. In computing, we have very important
concepts of "portability" and "interoperability." We also have
the idea of "levels of abstraction"--VERY IMPORTANT to allow the
construction of complex software.
>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.
I think whether or not one "scoffs" is irrelevant.
>Is cultured (and conventially promoted)
>ignorance of the basics of the craft consistent with engineering practise?
See my points above. (Is your question an example of conventionally
promoted ignorance?)
I don't feel that good engineering is practiced in computing. That
doesn't mean Software Engineering doesn't exist.
>Quite literally, people are discouraged from obtaining a practical knowledge
>of computing that needs to be *supplemented* -- but not replaced -- by a
>knowledge of theory [...]
I've never known this to be the case. Not for me, anyway.
>(people who know machine codes for Motorola processors by heart but
>can't tell you what is wrong with a bubble sort are a liability) [...]
That depends on the person's responsiblities.
>An engineer or team of engineers needs be well rounded and
>firmly grounded to bring a project home (to SPEC and on BUDGET! [dammit]).
Definitely.
>Frankly, the approach to object oriented technologies has done more to
>exacerbate this problem, because too much emphasis is placed on design.
I would say that, while OO technologies and techniques have solved
some problems, they have uncovered others. Too much hype has made
"OO" look bad in some ways.
>[...]
-t
--
"language is a virus from outer space
and hearing your name is better than
seeing your face." -- wm. burroughs, as paraphrased by laurie anderson
Thomas Andrews
>
>Stine tells a story about (some German rocket scientist; embarrassingly, I
>can't recall which) whose early experience was as a lab assistant, whose
>early tasks would include filing (by hand) a round piece of metal into a
>perfect cube. The traditional training of an engineer was hands-on (so Stine
>claims -- my degree is in mathematics and computer science) and the
>intuitive understanding gained by such labours proved invaluable foundation
>for their work.
>
>'Hacking' can be a perjorative term for the computing equivalent of filing
>round chunks of metal into perfect cubes . . . by hand.
>
The difference being, your future engineer knows what a perfect cube
is supposed to look like, while the hacker has no idea what good code
looks like...
--
Thomas Andrews Email: tho...@centerline.com
CenterLine Software WWW: http://draco.centerline.com:8080/~thomaso/
Kent Mitchell
: 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,
: to separate engineering from other disciplines.
Now I don't directly contradict what you say WRT not building test articles
as that if often true when building a simple version of a classic problem
(let's say a bridge crossing a resonable sized river). However, when
designing a whole new thing (like let's say a new jet engine) component level
testing is very important. For example, nobody would build a jet engine
from all of it's parts and bolt it all together and fire it up for the
first time to "see what happens". They will design each part and the
individual parts will have specs (length/width,etc and strength ...) they
test a few of these parts and then the build up the next larger assembly
and test it (like ballance, etc.) Until the get a complete working unit.
However, there are people if software that have the faith that they don't
need to do this kind of "unit" level software testing that they can just
wait until it is all integrated together and "system" test at the end.
Now I don't have a problem with systems test but it just seems a little odd
that we have people who think that they don't need to unit test.
--
Kent Mitchell | One possible reason that things aren't
Technical Consultant | going according to plan is .....
Rational Software Corporation | that there never *was* a plan!
Rob Broadhead
>of is not going to design very successful bridges. If he designs it
>assuming that steel will be used and tin is substituted, the bridge will
>likely fall.
>
My point was not that an engineer doesn't need to know what materials are
available, but the engineer should not design something and then mandate
that certain tools or materials be used. If there are constraints like
time, money, resources, then the engineer should build that into the
design. The design should not dictate the implementation.
---Rob
Jonathan Allan
|> In article <3ulu4u$j...@starbase.neosoft.com>,
|> Orpheus <ti...@Starbase.NeoSoft.COM> wrote:
|> >>After reading an guest editorial by G Harry Stine in the June 1995 edition of
|> >>_Analog_, I came to two startling conclusions:
|> round chunks of metal into perfect cubes . . .
|> To bring this down to a personal level, I've found that my early experience
|> with computers in which I mostly 'hacked around' and explored the machine and
|> dabbled (a sort of technical dilettantetism (sp?)) has continued to be of
|> great value to me combined with a formal education. Abstraction without
|> pragmatic knowledge at least weakens, if it does not handicap, an ability
|> to engineer. (I have anecdotes, but I don't want to bore people.)
Me too. I have fond memories of digging through the APPLE ][
DOS at 2 am... And a strong appreciation, if not actual
understanding, for what is going on "under the covers" that
many of my peers just don't have (and no amount of explaining
seems to allow them to get)! (Note that my education hasn't
been limited to the APPLE ][, I've dug into other systems:
MVS, VM, OS/400, a bit of UNIX, OS/9; I've even written
some real-time code - talk about an experience... 8-)
|> (I often joke that at a certain level its all boxes connected
|> by lines and at a certain level all it requires is a relabelling to determine
|> whether you've just designed software for a network router, an apartment
|> complex, or a new circuit board -- but that is a joke).
Not a joke. You should see my diagram for the wiring I'm
going to install in my basement. Lots of pretty colors! O8-))
[slice]
|> >A Software Engineer is not necessarilly working with A COMPILER. It
|> >could be MANY compilers or none. In computing, we have very important
|> >concepts of "portability" and "interoperability." We also have
|> >the idea of "levels of abstraction"--VERY IMPORTANT to allow the
|> >construction of complex software.
|>
|> In fact, my experience has been that pragmatic knowledge is useful even there,
|> since coding for portability has often meant understanding the common features
|> and limitations of the target machines. This idea of abstraction and division
|> of labour is of course quite common in other fields, which have the benefit
|> of longevity establishing conventional roles (architect, carpenter and
|> plumber, for instance). I suspect that software engineering suffers a good
|> deal from an inability to definitely pinpoint the optimal point for fracturing
|> the field into 'levels of abstraction'. And it just doesn't have the con-
|> ventions of age, nor do analogies with other fields longer established wholly
|> help. And levels of abstractions are seldom clean. Typically both the
|> architect and carpenter are familiar with the properties of woods, although
|> their experience of the medium and application of the knowledge is different.
Well said! Though I wonder where the difference is going to
break 100 years from now between the architect and the
carpenter. Information technology is changing *everything*.
Jonathan (Ah, Philosophy. You mean I might need that?) Allan
My copy of The Blue and The Brown Books is safe, where's yours?
Jonathan Allan
|> Marshall Woodson (M.B.W...@larc.nasa.gov) wrote:
|> : 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.
|> : It is the requirement to produce
|> : to separate engineering from other disciplines.
|>
|> Now I don't directly contradict what you say WRT not building test articles
|> as that if often true when building a simple version of a classic problem
|> (let's say a bridge crossing a resonable sized river).
You could consider the Tacoma Narrows bridge a test
article. Likewise all the cathedrals in Europe which fell
down or had to be modified from the original plans.
What are the "classic designs" for software going to be?
Are we even far enough along to *have* classic designs??
|> However, there are people if software that have the faith that they don't
|> need to do this kind of "unit" level software testing that they can just
|> wait until it is all integrated together and "system" test at the end.
|> Now I don't have a problem with systems test but it just seems a little odd
|> that we have people who think that they don't need to unit test.
Amen.
Jonathan Allan
Rick DeNatale
> 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.
Any bridge designer who cares not what his bridges are to be constructed
of is not going to design very successful bridges. If he designs it
assuming that steel will be used and tin is substituted, the bridge will
likely fall.
An Engineer even when designing with conventional materials and technology
must be aware of the characteristics of the materials and the expected
results of applying the appropriate techniques for working those
materials.
In the real world design and implementation cannot be separated. It might
seem that way if we are walking well known paths and have internalized the
"rules of thumb" to the extent that we no longer realize how we are doing
what we are doing, but just because the coupling might be subconscious
doesn't make it less real.
--
Rick DeNatale
Still trying to come up with a really cool Signature
Curt Welch - RDR
>In article <3umidd$j...@rational.rational.com>, k...@rational.com (Kent Mitchell)
> writes:
>|> Marshall Woodson (M.B.W...@larc.nasa.gov) wrote:
>|> : 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.
Yes, many times it's impractical, but it's exactly the same probelm with
software engineering - there is no real difference. Software developement
is engineering, and has all the same problems to deal with.
Projects (software or other engineering) are only undertaken if they seem
to be worthwile. For companies, this translates to looking at the cost
vs the expectected return on the work. They won't do the project if they
don't expect to make money on it.
Software development is generally much less expensive than other
engineering projects, but still, whatever the software is expected to
cost must be paid for.
In both types of development, you will always look for the
cheapest solution. Prototypes will be built only if they are
exptected to reduce the overall cost of the project. And
building something you expect to throw away is obviously
not a very cheap solution - it's only done when building
the real thing is very likely to fail without the knowledge
gained from the prototype.
You might think that because software is so cheap to develop, that
building a prototype is more likely to be a viable option in software
development than in other engineering. After all, it's a hell of a lot
cheaper to whip up a few screens than to build a bridge isn't it?
But this isn't the case. A prototype in software is cheaper than a
bridge, but the overall amount of money available for the software
project is also orders of magnatude less than the money on the bridge
project. If you only have 6 months worth of money to develop some
software, will spending 3 months developing a prototype help you get it
done quicker? Not likely.
Building a prototype will always help you produce a better product.
Just like the concept of writing all software twice. Do it once, then
throw it away and do a scond time by fix all the things you did wrong
the first time. There's no question in my mind about whether this produces
better software, but it's seldom the most cost effective alternative.
Doing it the best way you know how, and then patching around the problems
you didn't foresee is almost always is the most cost effective alternative.
Another big difference in Software engineering and other engineering
that few people understand is caused by the huge difference in engineering
vs other costs in the projects. When you build a small bridge, you might
spend 100 million on the project, but only 1 million is the enginerring
costs (I know nothing about building bridges, so these numbers may be
off - but the concept is valid...). Most of the money is not engineering,
it's construction costs. When you build software, you might spend
1 million on the project, but almost all of that is engineering costs.
How much does it take to copy the disk once the software is completed?
If the engineering on the bridge project ends up taking twice as much
work as expected, then they only blow their budget by 1%. If this
happens on a software project, then your budget is 100% over.
Also, because the engineering on a bridge project is such a small
percentage of the cost, then it's easy to pad the budget and
allocate twice as much time as you might need - so it's easy to
keep the engineering costs within budget.
On (most) software projects, you don't get to do this. The difference
between taking 6 months and 12 months to develop software can
make or break the project.
I think more prototyping is done in Software than other work,
but it's not because it's cheap to develop softwate, but because
software development projects are typically more risky, so it's
more likely that the time spent on a prototype will actually
save time overall on the project.
The reason Software development is more risky is because you
seldome have to develop the same software twice. If you need
the same software again, or something very similar, but only
slightly different, then you use your old work to develop
the new. So, the first project might have cost 1 million, but
the second variation only cost 5 thousand. If you build two
bridges that are basically the same, the first will cost
100 million, and the second will cost 100 million.
If you do a second large software project, then by defintion,
you are doing something you have never done before - and
there will be lots of risk envolved.
People look at the two 100 million dollar bridge projects and try to
compare them to two large software projects. They wonder why the
software projects are so likely to fail, when the civil engineers seem
to have no problem building all those bridges. It's not a fair
comparison. Microsoft would have no development problems at all
if everyone that wanted to buy windows was willing to pay the 100
million development cost and allow them to re-write the OS for
each user. After 2 or 3 times, they might even get it "right" :-).
The large numbers of failures in software projects is simply
due to the fact that software development projects are almost
always much riskier than other engineering projects. And if you
don't correctly budget for that risk (which is almost never done) the
project will have a high probability of failure.
There are many examples of risky engineering projects. NASA's project
to send a man to the moon is a good one. Did they just try to build
one rocket and send it to the moon? Now way. They built thousands of
prototypes of everything. And many of those prototypes blew up on the
pad.
But they got the man to the moon in the end because they had a large
enough budget to make it work.
Few people that sponsor large software development projects are willing to
believe how risky they really are, so they are seldom willing to
budget the amount of time and money required to guareent the projects
success. And at the same time, many new developers also don't understand
how risky the project is, so they don't demand the size budget required.
>|> : It is the requirement to produce
>|> : theoretical and analytical models of physical systems which tends
>|> : to separate engineering from other disciplines.
>|>
>|> Now I don't directly contradict what you say WRT not building test articles
>|> as that if often true when building a simple version of a classic problem
>|> (let's say a bridge crossing a resonable sized river).
>
>You could consider the Tacoma Narrows bridge a test
>article. Likewise all the cathedrals in Europe which fell
>down or had to be modified from the original plans.
>What are the "classic designs" for software going to be?
>Are we even far enough along to *have* classic designs??
You must new to software if you think that we aren't far
enough along to have classic designs. MS-DOS, was based
on CPM and UNIX. CPM was based on older DEC operating systems.
Unix was built on a lot of concepts from Multics, etc...
All these in my mind are old classic designs in software.
Curt Welch
cu...@kcwc.com
Steve Mellor
Rick DeNatale wrote:
> Any bridge designer who cares not what his bridges are to be constructed
> of is not going to design very successful bridges. If he designs it
> assuming that steel will be used and tin is substituted, the bridge will
> likely fall.
>
> An Engineer even when designing with conventional materials and technology
> must be aware of the characteristics of the materials and the expected
> results of applying the appropriate techniques for working those
> materials.
In my opinion, these two paragraphs are contradictory. In paragraph 1,
Mr DeNatale suggests that I need to know what the material is.
In paragraph 2 OTOH, he says that I need to know about the _characteristics_
of the materials. These are different. Do I want steel? Or do I want
any material that has at least t tensile strength; withstand s1 stress,
and s2 strain; has a density less than d, etc etc etc?
I claim it's the latter. Put yourself in the position of the materials
designer. Do you want to be told "The requirement is steel" or do
you want to the freedom to find the best material that meets the
true requirements??
>
> In the real world design and implementation cannot be separated. It might
> seem that way if we are walking well known paths and have internalized the
> "rules of thumb" to the extent that we no longer realize how we are doing
> what we are doing, but just because the coupling might be subconscious
> doesn't make it less real.
>
As a result of the unrecognized contradiction above, Mr DeNatale draws
a conclusion that is somewhat overstated. It would be more accurate to say
that we should make explicit the assumptions about the implementation,
but we should not constrain it.
Software engineering methods attempt to determine what information should
be carried from step to step, and they (should) attempt to minimize
the amount of information, so that we can more easily manipulate it.
If you hold the view that you always need to know everything,
which I assume Mr DeNatale does, then you are drawn to the conclusion
asserted in the subject line "Software Engineering Doesn't Exist"
--
Steve Mellor st...@projtech.com
Project Technology, Inc. ...!uunet!projtech!steve
2560 Ninth Street, Suite 214 Voice: +1 510-845-1484
Berkeley CA 94710, USA Fax: +1 510-845-1075
**** Training and Consulting in the Shlaer-Mellor method ****
Scott A. Whitmire
>In a thread "Software Engineering Doesn't Exist [was: C Hackers]"
>Rick DeNatale wrote:
>
>> Any bridge designer who cares not what his bridges are to be constructed
>> of is not going to design very successful bridges. If he designs it
>> assuming that steel will be used and tin is substituted, the bridge will
>> likely fall.
>>
>> An Engineer even when designing with conventional materials and technology
>> must be aware of the characteristics of the materials and the expected
>> results of applying the appropriate techniques for working those
>> materials.
>In my opinion, these two paragraphs are contradictory. In paragraph 1,
>Mr DeNatale suggests that I need to know what the material is.
>In paragraph 2 OTOH, he says that I need to know about the _characteristics_
>of the materials. These are different. Do I want steel? Or do I want
>any material that has at least t tensile strength; withstand s1 stress,
>and s2 strain; has a density less than d, etc etc etc?
No, they are NOT contradictory. Read them again. I had to. In building materials,
if you specify a tensile strength, stressability, strain resistance, and density,
you generally end up with one or two materials. From there, you use availability,
cost, or ease of working with it, to select one.
>
>I claim it's the latter. Put yourself in the position of the materials
>designer. Do you want to be told "The requirement is steel" or do
>you want to the freedom to find the best material that meets the
>true requirements??
>
The structural engineer's job is to design the bridge to meet the required specificaions
and loads. Part of that job is determining the materials to be used.
>>
>> In the real world design and implementation cannot be separated. It might
>> seem that way if we are walking well known paths and have internalized the
>> "rules of thumb" to the extent that we no longer realize how we are doing
>> what we are doing, but just because the coupling might be subconscious
>> doesn't make it less real.
>>
>
>As a result of the unrecognized contradiction above, Mr DeNatale draws
>a conclusion that is somewhat overstated. It would be more accurate to say
>that we should make explicit the assumptions about the implementation,
>but we should not constrain it.
There is no contradiction above. And I don't think the conclusion is overstated.
Isn't the point of design to determine the implementation that best meets the
requirements? Analysis determines WHAT a system is to do (be it software, bridge,
business, or whatever), and design determines HOW the system does the WHAT. If you
separate design from implementation, you never get the thing built.
>
>Software engineering methods attempt to determine what information should
>be carried from step to step, and they (should) attempt to minimize
>the amount of information, so that we can more easily manipulate it.
>If you hold the view that you always need to know everything,
>which I assume Mr DeNatale does, then you are drawn to the conclusion
>asserted in the subject line "Software Engineering Doesn't Exist"
>
No, that's not quite right. While it is not necessary to know everything when you
start design, it is necessary to know everything when you finish it. And software
engineering does exists, but it is not a "what," it is a "how." You can build software
by "hacking" it together, or you can engineer it. Engineering implies formally (here
meaning deliberately) making tradeoffs among alternatives, using as objective and
quantitative methods as are available, in order to meet both the requirements and
the constraints. This involves some very deliberate actions such as analysis of a
design (walkthroughs, reviews, and inspections are examples), calculation of certain
measures, testing of hypotheses (which first requires MAKING those hypotheses), and
other actions (borrowed from the scientific method).
Scott A. Whitmire sco...@advsysres.com
Advanced Systems Research
25238 127th Avenue SE tel:(206)631-7868
Kent Washington 98031 fax:(206)630-2238
Consultants in object-oriented development and software metrics.
Scott A. Whitmire
>
>In civil engineering, be it bridge design, building design, dam
>design, etc., the implementation details *must* be considered
>very early in the design process.
>
>Now I'm not advocating that we do the same in software engineering.
>I think at this point the analogy is essentially broken.
>
But, I have found that we MUST do the same is software engineering. We ignore
the implementation details to our peril. Now, most of the time, this isn't a problem,
since, for any given design feature, we've either implemented it before, or know of
an implementation. However, if we design a feature that we have not implemented, have
no immediate idea of how to implement it, and know of no other attempt to implement
it, we'd better just drop everything and try to implement it with a prototype, to see
if it can be implemented. If you read about the history of the construction of the
pyramids in Egypt, and the cathedrals in France, you will understand what happens when
design does not take implementation details into account. (For those of you who don't
know that history, there is considerable evidence, and some documentation, of
mid-construction design changes because something didn't work. The builders of these
structures relied heavily on experimentation and failure to see what worked and what
didn't).
I'm not sure the analogy is broken. I'm not real sure it's even any weaker. My own
experience tells me otherwise. My methods have gotten more formal, and I spend far more
time in design working on implementation details than I used to. This is for several
reasons: the quality of both my designs and the resulting software keep improving, and
I am able to handle more difficult problems by myself than I could even imagine doing
several years ago.
Rick DeNatale
Whitmire) wrote:
> In <1995Jul21....@projtech.com>, st...@projtech.com (Steve
Mellor) writes:
> >Rick DeNatale wrote:
> >
> >> Any bridge designer who cares not what his bridges are to be constructed
> >> of is not going to design very successful bridges. If he designs it
> >> assuming that steel will be used and tin is substituted, the bridge will
> >> likely fall.
> >>
> >> An Engineer even when designing with conventional materials and technology
> >> must be aware of the characteristics of the materials and the expected
> >> results of applying the appropriate techniques for working those
> >> materials.
> >In my opinion, these two paragraphs are contradictory.> No, they are
NOT contradictory. Read them again. I had to.
... remainder of an excellent posting truncated
Scott,
I had prepared a reply to Steve Mellor's posting, and had decided to save
it and look it over after getting some sleep (It's two a.m. as I sit
here).
I should have read ahead and saved the trouble, you pretty much stated
exactly what I would have said, and better than I would have (at least at
this hour).
And I'm sure that I could have done better with the controversial two
paragraphs, but as I remember I wrote those pretty late at night/early in
the morning as well.
Michael Veksler
: 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?)
Do you really think that structural engineers *build* their bridges, they
have workers to do that. They know what the workers should do (more or less),
but they probably can't do it themselves without breaking something.
Software engineers use compilers instead of workers, if they will
try to do the work themselves, they may break something too.
: 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?
Actually, all software engineers I know have some basic knowledge in
assembly and CPU structure (pipelines, superscalar, multiprocessors, etc.).
You must know that so you don't expect too much of your compiler and
write your C code properly (As long as it does not hurt maintainability).
We are taught at our third-fifth semesters about the internals:
Assembly, computer structure, OS structure, compilation,
Writing 2000 lines of code as a homework is pretty ordinary
(I had written 2 programs 3000 lines of lisp code for an AI course).
On the other hand we learn much theory (I actually loved this part).
I don't know what other institutes/universities do.
: Frankly, the approach to object oriented technologies has done more to
: exacerbate this problem, because too much emphasis is placed on design.
: This may partially be the direction in which the pendulum has swung from
: early days when too little attention was paid design, and partially because
: in the early days of object technologies it was valuable to gloss over the
: chief liability (performance) as inconsequential and overrated by [err, umm]
: hackers. (Many real world applications are dominated by their execution
: constants rather than number of iterations/recursions.)
You are wrong, OO design is a great thing. I have been a c hacker at school,
written assembly code for my Commodore-64 (That was THE PC of those days).
Optimized every instruction so my program (or interrupt handler) will fit
into xx Kb. I knew nothing about design, OO-design could have saved
me a lot of time (I had to rewrite things all over after I discovered
that the data-structure was not good enough for the task in hand).
OO is a great thing, but it can't be applied for every task, some tasks
simply can't be referred to as objects. For those tasks there are other
analysis techniques like OPD, BFD.
Did you hear of OPD (Object-Process-Design) ?
You should try it. It takes the good things of the two worlds of OO and
process Analysis/Design.
Michael
Jonah Thomas
e1678223%PROBLEM_WITH_IN...@discus.technion.ac.il (Michael
Veksler) writes:
>: 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?)
>Do you really think that structural engineers *build* their bridges,
>they have workers to do that. They know what the workers should do
>(more or less), but they probably can't do it themselves without
>breaking something. Software engineers use compilers instead of
>workers, if they will try to do the work themselves, they may break
>something too.
That's part of the problem when engineers try to build in the third
world, right? A lot of what they think they know is really informal
knowledge owned by the contractors and construction workers. Go
somewhere that this knowledge base is different, and nothing works.
Sometimes problems come from things as simple as bamboo scaffolding.
That's part of the reason they so often import construction crews as
well as engineers.
It would be nice if the hidden knowledge was available, but it's
cheaper to just use what's available. And it mostly just works,
except when there's a strike or you try to build outside the culture.
>: Frankly, the approach to object oriented technologies has done
>: more to exacerbate this problem, because too much emphasis is
>: placed on design. This may partially be the direction in which
>: the pendulum has swung from early days when too little attention
>: was paid design, and partially because in the early days of
>: object technologies it was valuable to gloss over the chief
>: liability (performance) as inconsequential and overrated by [err,
>: umm] hackers. (Many real world applications are dominated by
>: their execution constants rather than number of
>: iterations/recursions.)
>You are wrong, OO design is a great thing. I have been a c hacker at
>school, written assembly code for my Commodore-64 (That was THE PC
>of those days). Optimized every instruction so my program (or
>interrupt handler) will fit into xx Kb. I knew nothing about
>design, OO-design could have saved me a lot of time (I had to
>rewrite things all over after I discovered that the data-structure
>was not good enough for the task in hand).
I wonder whether OO-design would have saved you time. You found out
the requirements by writing the code the first time. It might have
taken significantly longer to do OO-design from scratch than to make
that first try. For projects that aren't too big, maybe it makes sense
to do a first pass and _then_ do OO-design, to save a lot of time on the
_third_ attempt. And for projects that are too big, OO-design isn't
likely to save the day. It might make the difference between a total
failure and a something that's unusable but comes close to meeting spec.
Eli Goldberg
>>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.
Yes, this is for the 15-12X series of courses at CMU, which
I took back when I was a freshman in '91. They called it the "mastery
exam".
They gave us a huge, huge program (well, by student standards; it's
hundreds of pages) and require that we make major changes to it. e.g.
convert the main data structure from an array to a linked list, or
implement some major functionality.
Anyone can pass the exam with a 'D' in 15 minutes, but it takes real
programming skills to get better than that.
It's not as good in practice as it sounds --- they give you a programming
assignment that's so complex that most students just have to memorize the
code before you take the exam, most students taking 20-60 hours to
prepare for the exam.
The end result, and why it's so widely disliked, is that most students
(at least when I took it) either:
1. Concluded that it wasn't worth wasting 50 hours of their time, and
took a C on the exam, ruining their grade. (like me)
2. Found someone with clue, and memorized their answer without
understanding what the code really did.
Andy Dent
>You could consider the Tacoma Narrows bridge a test
>article.
Come on guys, Civil Engineering is just one branch of engineering. If you
don't want to consider electrical, at least draw your analogies from the
Mechanical Engineering world. There they deal with complex machines
assembled from other complex parts, the end product may have a short life
and they DO use component level testing.
Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/oofile/
http://www.highway1.com.au/adsoftware/oofile.html
im...@inforamp.net
>>design, etc., the implementation details *must* be considered
>>very early in the design process.
>>
>>Now I'm not advocating that we do the same in software engineering.
>>I think at this point the analogy is essentially broken.
>>
>
>experience tells me otherwise. My methods have gotten more formal, and I spend far more
>time in design working on implementation details than I used to. This is for several
>reasons: the quality of both my designs and the resulting software keep improving, and
>I am able to handle more difficult problems by myself than I could even imagine doing
>several years ago.
While the point I will try to make does not necessarily try to agree or disagree with any
of opinions above, they inspired me to post a reply here.
I haven't read the original text that the discussion is about, and sometimes I find it difficult
to exactly understand what people are trying to say because of complicated 'intelektsia'
language.
But it seems to me that (in general) everyone is missing a point (or two):
When a bridge is about to be built, there is no such thing as THE engineer. There
is a whole team of experts in their fields (geologist, architects, structural engineers, ets.)
Each looks at the problem domain from a different angle and ASSUMES the other experts
will make the right decisions in their field. This assumption is more of a qualitative nature,
not necessarily related to any particular material. (i.e., an ingeneers is concerned with
QUALITIES of matter they are working with, not if it's steel or tin). So they have to have
understanding of interactions between physical qualities more than anything else. They
start wandering about what material to use when they know what qualities it should have.
(So much for division of labour between designers and hackers...)
Accordingly, in software engineering we have (or should have) more expertise to deal with
than 'just' design and coding. There are other issues - ranging from overall architecture of
a particular system to the 'popular culture' in which the system is going to be built.
(bridge building technology differs - rope bridges in India are built differently than steel and
concrete bridges of western world).
/------------------------------------------------------------------------------
/ Jerry Kott
/ Imageware Corporation - "Connecting Objects to a Perfect Image"
/ Toronto, Ontario, Canada, Earth, Solar System, Milky Way, The Universe, ???
/ (416) 431-3196
/------------------------------------------------------------------------------
Patrick Frend
Sorry to but in, but IMHO but the above paragraph seems to me to be the reason
there are so many failure, not only in the software world, but in other areas
also.
Analysis is NOT to determine "WHAT a system is to do" its is to determine
"WHAT THE PROBLEM IS", and what constraints this puts on the design "WHAT IS
NEEDED".i.e I need a bridge to cross a river 1Km wide and it must allow ships
to pass. I need to store and retreive medical records.
Design is to determine what solutions are possible "WHAT I COULD DO".
Suspention bridge, causeway with lifting section. Database based on a widely
available database engine which will store name,age, sex etc. Note. at this
point I don't even need to know which database engine I am to use; but I do
know what database engines can do.
Implementation is choosing and refining the disign into a workable solution
"WHAT I am going to do, and How am I going to do it". Suspension bridge, steel
from jo boggs, concrete from X. This does not mean this stage is the end, but
it may be the last stage for the designer/engineer.
Finaly the implementation is coded. The bridge is built, the code is typed in.
With software engineering, it is even posible to delay choosing the
implementation languages (note plural) until this point.
>>
>>Software engineering methods attempt to determine what information should
>>be carried from step to step, and they (should) attempt to minimize
>>the amount of information, so that we can more easily manipulate it.
>>If you hold the view that you always need to know everything,
>>which I assume Mr DeNatale does, then you are drawn to the conclusion
>>asserted in the subject line "Software Engineering Doesn't Exist"
>>
>
>No, that's not quite right. While it is not necessary to know everything when you
>start design, it is necessary to know everything when you finish it. And software
>engineering does exists, but it is not a "what," it is a "how." You can build software
>by "hacking" it together, or you can engineer it. Engineering implies formally (here
>meaning deliberately) making tradeoffs among alternatives, using as objective and
>quantitative methods as are available, in order to meet both the requirements and
>the constraints. This involves some very deliberate actions such as analysis of a
>design (walkthroughs, reviews, and inspections are examples), calculation of certain
>measures, testing of hypotheses (which first requires MAKING those hypotheses), and
>other actions (borrowed from the scientific method).
>
>
>Scott A. Whitmire sco...@advsysres.com
>Advanced Systems Research
>25238 127th Avenue SE tel:(206)631-7868
>Kent Washington 98031 fax:(206)630-2238
>
>Consultants in object-oriented development and software metrics.
>
--
---------------------------------------------------------------------
Patrick Frend | email:
Schlumberger Technologies, | fr...@ferndown.ate.slb.com
Ferndown Industrial Estate, | phone:
Wimborne, | +44-1202-850823 (850850 alt.)
Dorset, BH21 7PP | fax:
England. | +44-1202-850990
---------------------------------------------------------------------
Jonathan Allan
|> In comp.lang.smalltalk, xzz...@honker.rchland.ibm.com (Jonathan Allan) writes:
|> There are many examples of risky engineering projects. NASA's project
|> to send a man to the moon is a good one. Did they just try to build
|> one rocket and send it to the moon? Now way. They built thousands of
|> prototypes of everything. And many of those prototypes blew up on the
|> pad.
If you consider all the rockets ever built to be
prototypes for the Saturn V, you might have a case.
To my knowledge, there were less than 10 Saturn
test articles before the first Apollo launch.
5 sticks in my mind, but I can't figure why.
|> But they got the man to the moon in the end because they had a large
|> enough budget to make it work.
Absolutley right.
|> Few people that sponsor large software development projects are willing to
|> believe how risky they really are, so they are seldom willing to
|> budget the amount of time and money required to guareent the projects
|> success. And at the same time, many new developers also don't understand
|> how risky the project is, so they don't demand the size budget required.
And when they do, they tend to get replaced.
|> >|> : It is the requirement to produce
|> >|> : theoretical and analytical models of physical systems which tends
|> >|> : to separate engineering from other disciplines.
|> >|>
|> >|> Now I don't directly contradict what you say WRT not building test articles
|> >|> as that if often true when building a simple version of a classic problem
|> >|> (let's say a bridge crossing a resonable sized river).
|> >
|> >You could consider the Tacoma Narrows bridge a test
|> >article. Likewise all the cathedrals in Europe which fell
|> >down or had to be modified from the original plans.
|> >What are the "classic designs" for software going to be?
|> >Are we even far enough along to *have* classic designs??
|>
|> You must new to software if you think that we aren't far
|> enough along to have classic designs. MS-DOS, was based
|> on CPM and UNIX. CPM was based on older DEC operating systems.
|> Unix was built on a lot of concepts from Multics, etc...
|>
|> All these in my mind are old classic designs in software.
Hmmmm. Does 15 years of practice and a lot of study
about prior art count as "new to software"? We've only
been at this software schtick for 40 years or so (depends
on what you define as software). We don't have enough
history yet to _have_ a historical perspective, and hence,
have "classic designs". Indeed, the first generation
of software architects is still alive, and in many cases,
still practicing. It's difficult to beatify a dead design
when the builders who know its flaws are still trying
to get it right somewhere else... O8-))
In fact, we have a real problem of undocumented designs
(can you say "trade secrets") such that students of the
art in coming decades will never be able to study the
"classic designs" in situ. How many machines, 100 years
from now, will be running CP/M? How many machines, 50
years from now, will be running MULTICS? How much of
design documentation (if there ever was any) will have
been preserved? Worse, how much will be intelligable
to the student 50 or 100 years from now? Do we sweep
PC-MOS (perhaps a bad example) under Histories Rug
because the source code was never released and the
design docs were shredded when the company filed for
chapter 7 dissolution?
The neat thing about civil or mechanical engineering
is, when the process is complete, you are very likely
to have an artifact that'll last a long, long, time
and can be studied by future people at thier leisure.
And when your artifact fails, there's usually an inquest
into why and how, and what do we do to not repeat
this disaster.
Taint so with software. We go through hardware too
fast. Just ask your favorite librarian or archivist
about long (100 years+) storage solutions. Be prepared
for some bitterness and bile; you'll get an earful
about nifty gizmos that look like the permanent answer,
and then the company dies a year or two later...
Others have noted that it won't be long before the
first multi-billion $$$$ lawsuit against a programming
house is launched because of failed software. But, as
of now, that hasn't happened; maybe we are still an
art and not an engineering field. Yet.
Jonathan (OK, off my soap box for a while) Allan
Eric Smith
Jared Nedzel <jne...@netcom.com> wrote:
>In article <3uoc7p$4...@handy.gr.com> Rob Broadhead <ro...@gr.com> writes:
>In civil engineering, be it bridge design, building design, dam
>design, etc., the implementation details *must* be considered
>very early in the design process.
>
>Now I'm not advocating that we do the same in software engineering.
>I think at this point the analogy is essentially broken.
Here's the real problem with the analogy between software engineering
and bridge design: A bridge consists of software and hardware. The
hardware is the materials. The software is the design, which makes it
a bridge instead of some other usage of the same materials. Bridge
design is like software development, and bridge construction is like
software publishing. The people who do the actual construction of
the bridge are doing the equivalent of making copies of floppy disks
and manuals. Of course what they are doing is much harder and more
complicated, because their materials are harder to work with. As if
software publishing workers had to make the floppy disks by hand, not
just copy the software onto them. But even more complicated than that,
because a lot more can go wrong when working with expensive and heavy
materials.
But the point is that the analogy isn't just broken. It's smashed to
pieces, beyond all recognition. When people try to use this analogy,
they just add to the confusion, and the thread goes on and on.
A much better analogy would be in movie making. The script is like the
software design, and the released movie is like the released software.
The performers, sets, special effects, etc., are like the programmers,
programming languages, compilers, etc.
But even that's an imperfect analogy. We have to be careful not to
rely too heavily on analogies for this kind of argument, because they
tend to cause more confusion than enlightenment.
Eric Smith
Steve Mellor <st...@projtech.com> wrote:
>designer. Do you want to be told "The requirement is steel" or do
>you want to the freedom to find the best material that meets the
>true requirements??
"Steel" is like a software package. That is, it's like a black box
with certain properties. You're saying you want to work with those
properties rather than with that black box. But the problem is that
there are too many properties to make it convenient to work with them
as a package unless you have a black box such as "steel".
For example, if you substitute a plastic for steel, you might discover
some property of steel you were relying on without knowing it. Your
past experience may have told you steel worked well for such designs,
but changing the material might tell you more of the reasons why it
worked than just the reasons you assumed.
Therefore, when you change the material, you have a new design, which
may or may not work reliably the way the old design worked. This is
very important in bridge design, because it takes decades to test a
bridge. It's important to experiment with designs, but it's important
to know you are doing so.
Danny R. Faught
John Sellers <sel...@sellers.com> wrote:
>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.
But I can examine the source code of the operating system ;-)
>Imagine, no system crashes!
Hmmm, depends on your specification. Most Earthlings would consider
old sol going supernova a pretty bad system glitch.
--
Danny Faught -- Convex -- Operating System Demolitions Specialist
Magister artis ingeniique largitor venter.
Kurt L Sussman
>In my experience, there are three type of programmers:
> <nice list deleted...>
I heard that list of three as
1. Engineer
2. Programmer
3. Coder
Where a coder can conceptualize an entire function, a programmer can
conceptualize an entire module, and an engineer can conceptualize a
complete system.
Obviously there are other differences; engineers care about failure
modes, understand the importance of testability, continue to study in
their field and in related fields, etc. Programmers are generally more
trainable, and coders are best left for the big companies to pick up
and train.
I find this list useful in categorizing people I interview...
--Kurt
_____________________________________________________________________
RadioMail Corp. "The basis of optimism is sheer terror"
http://www.radiomail.net/ --Oscar Wilde
Jean1112
(material concerning bridge-building analogy deleted)
>A much better analogy would be in movie making. The script is like the
>software design, and the released movie is like the released software.
>The performers, sets, special effects, etc., are like the programmers,
>programming languages, compilers, etc.
>But even that's an imperfect analogy. We have to be careful not to
>rely too heavily on analogies for this kind of argument, because they
>tend to cause more confusion than enlightenment.
I've heard the movie making analology applied to software before. It's a
nice analogy in that there are a lot of creative people involved, each
with very specific specialties. All of them have to work together for the
finished movie to be worth watching.
It would also be amusing to think about whether a software team needed a
director, a producer, etc. (and who would get to play the role of the
villain and the leading man -- picture Tommy Lee Jones on ** your **
latest project!)...
One place where the analogy breaks down is the temporary nature of a
movie. Movie teams come together for an intense period of time, everyone
does their work and then goes on to the next movie. No one has to extend
or maintain the thing. No one (except the producer, maybe) has lives
depending on the outcome of the movie, yet some software is used in
man-rated applications. In other words, software is much longer-lived and
has to be managed for a wider variety of uses than a movie.
Regards, Jean Stanford
Hestia Systems Requirements Elicitation / Software CM / Software Team
Facilitation
Chip Salzenberg
>In article <3uk6lr$1...@bmerhc5e.bnr.ca>, dbsh...@bnr.ca says...
>>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).
>
>that like nuclear phisicist? I do not think so (at least in general case -
>if it is a bridge and not a nuclear device)!
Yes, he must know about those details -- but he might know them as random
facts (steel rusts, suffers fatigue, can hold a magnetic direction, etc.).
Knowledge need not be explicit and use big words to be real.
It's similar to the way people today know that OS/2 "crashes less"
than Win3.1, or that Netware "is faster than" Lan Manager; they don't
know why in the way that we computer geeks know why, but they are in
their own way taking implementation details into account when making
their decisions.
--
Chip Salzenberg, aka <c...@nando.net>
"And remember to worship at the railroad of your choice."
-- Mike Nelson, MST3K: "The Amazing Transparent Man"
Hamish Jon Murphy
>nice analogy in that there are a lot of creative people involved, each
>with very specific specialties. All of them have to work together for the
>finished movie to be worth watching.
>
>It would also be amusing to think about whether a software team needed a
>director, a producer, etc. (and who would get to play the role of the
>villain and the leading man -- picture Tommy Lee Jones on ** your **
>latest project!)...
>
>One place where the analogy breaks down is the temporary nature of a
>movie. Movie teams come together for an intense period of time, everyone
>does their work and then goes on to the next movie. No one has to extend
>or maintain the thing. No one (except the producer, maybe) has lives
>depending on the outcome of the movie, yet some software is used in
>man-rated applications. In other words, software is much longer-lived and
>has to be managed for a wider variety of uses than a movie.
>
>Regards, Jean Stanford
>Hestia Systems Requirements Elicitation / Software CM / Software Team
>Facilitation
>
an architectual firm. Architects/draftsmen are the programmers/analysts. Design
tools such as pencils, T-squares, draft boards, (and ofcourse CAD programs) all
represent compilers, text editors, computer desktops, and the like. Clients (as
they will ever be) are clients.
Architects must survey clients and landsites to come up with an initial design.
Similarly, analysts must interview potential users and survey particular
platforms, to decide on an initial design.
Clients change their minds and tell you that they wanted a second bathroom
after all, right after you've completed the first draft. Need I explain the
comparison?
Architects must draft up legal documents so that engineers and construction
workers can complete their tasks while comforming to design and local legal
constaints to complete implementation. Programmers must document their code (I
really enjoy that part (sarcasm)) and their coding must comform to the semantic
and syntactical constraints imposed by the programming platform.
A structure must be analysed and proven to be designed to withstand most of the
environmental conditions. Clients may or may not choose various asthetic
appearances of the building. A program must be tried and tested to see if it
works in the clients environment. Its visual impact may or may not be
determined b potential users.
The building is then complete, and can be used, as is an application.
Finally, a building may get old, and further extensions may be required; or
maybe the building is completely demolished to make way for a new one. All
designs may be handled by the original architect(s) or by a new firm. Once an
application has served its purpose, new features may be added; or a complete
rewrite may be necessary. Coding may be handled by the original developers or
by a new company.
So there you have it. I would add more, but the analogy is not that ethralling.
Stefan Froehlich
: Hmmm, depends on your specification. Most Earthlings would consider
: old sol going supernova a pretty bad system glitch.
Well, for Version 1.0 it has been stable quite for a long time.
Bye, Stefan
Keith Hood 4652
>In article <NEWTNews.8060550...@sellers.sellers.com>,
>John Sellers <sel...@sellers.com> wrote:
>>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.
>
>But I can examine the source code of the operating system ;-)
>
>
>Hmmm, depends on your specification. Most Earthlings would consider
>old sol going supernova a pretty bad system glitch.
Only if it wasn't in the reqirements
Keith
---
Opinions are my own but are open to any reasonable offer
Michael Kan
>
> But this isn't the case. A prototype in software is cheaper than a
> bridge, but the overall amount of money available for the software
> project is also orders of magnatude less than the money on the bridge
> project. If you only have 6 months worth of money to develop some
> software, will spending 3 months developing a prototype help you get it
> done quicker? Not likely.
>
Perhaps the thing to do is to find another way to prototype rather than
discard the idea altogether. One alternative might be lower resolution
prototyping such as using paper mockups. 3rd world transportation projects
sometimes involved paved roads when only a trail was needed. What was
needed was 'appropriate technology' - use gravel when gravel makes sense,
use 8 lane freeways when that makes sense. In the case of prototyping, use
paper mockups when that makes sense, use Visual Basic mockups when that
makes sense.
And sometimes, yes, don't prototype because there isn't time, you can't
get the person(s) involved to reply in time, etc. Prototype at the level
that gives a reasonable Return On Investment but don't assume that a
prototype must be a full app unto itself.
--
::: mike kan :::
Alan & Helene Hinden
PRESS RELEASE
3755 East Desert Inn Road Las Vegas, NV 89121 702-877-4633 Fax: 702-731-0375
For Immediate Release
Date: July 26, 1995
Contact: Alan W. Hinden
Phone: 702-877-4633
Fax: 702-731-0375
A CONSUMER ADVOCATE FOR BUSINESSES-LARGE & SMALL
Las Vegas, Nevada
Isn t a consumer advocate for businesses a contradiction in terms? Not really,
businesses are consumers too. When businesses get taken, they get taken Big Time -
especially in the area of computer hardware, software and office equipment.
Alan Hinden is a militant consumer. Don t let them get away with anything, he
says, referring to manufacturers. The trend for the past few decades has been to get
consumer products to market by the deadline , whether they work properly or not.
Many products start with good design and planning, only to have quality sacrificed as
the deadline approaches. That s why, at first glance, so many products look better
than they really are, says Hinden.
Manufacturers deal with problems later . . . maybe, he said. That s why Space
Shuttles, airplanes, cars and computer systems crash! They put the dollars first, the
consumer last, and literally pick up the pieces later if they have to.
Computer software developers are some of the most notorious in this arena. Too
many computer programs do not live up to their hype, especially in claims of full
featured, user friendly or ease of use.
Hinden specializes in helping business consumers test and evaluate computer
hardware and software for ease of use, functionality and usability before they take the
big plunge into something they regret many thousands of dollars later.
After Hinden runs the proposed equipment and software through the ringer, his
clients have a reasonable understanding of how well or how poorly the products will
meet their needs.
It s all too common for consumers to believe what programmers with no sense of
simplicity, or salespeople with limited knowledge, tell them. They then spend
thousands of dollars and employee hours in the transition, and find out too late, that
they have a very expensive nightmare on their hands.
It s good business sense, to have an objective small scale evaluation of equipment and
software, by an independent third party. One who specializes in testing and
evaluation, and doesn t sell equipment or software - a consumer advocate for
businesses.
With over ten years of product testing & evaluation experience, Hinden
is available
for consultation at 702-877-4633 or E-mail address
rev4...@ix.netcom.com
He is a former Newspaper columnist, radio talk show host & TV
personality who
concentrated on consumer education.
--
||=========================================================||
|| People Are... ||
|| More Important Than Money, Power, Time and "Stuff". ||
|| When People Love People More Than These, ||
|| War Poverty & Hunger Will Be History. ||
||=========================================================||
Rev. Alan W. Hinden, rev4...@ix.netcom.com
MAKE YOUR OPINIONS REALLY COUNT
A PIPELINE TO THE PRESIDENT & CONGRESS IS NOW IN OPERATION
Word Wide Web http://www.mindspring.com/~gsandow/natleg.html
Steve Mellor
> Steve Mellor <st...@projtech.com> wrote:
> >designer. Do you want to be told "The requirement is steel" or do
> >you want to the freedom to find the best material that meets the
> >true requirements??
>
> "Steel" is like a software package. That is, it's like a black box
> with certain properties. You're saying you want to work with those
> properties rather than with that black box. But the problem is that
> there are too many properties to make it convenient to work with them
> as a package unless you have a black box such as "steel".
Thank you! Thank you for distinguishing between knowledge about the
thing--in this example steel--and properties of the thing, in the
example, density, stress, strain etc.
And you have a good point: One name for the collection of _properties_
could be "steel", but let's understand that this stands for "any
steel-like substance" within constraints that you delineate later.
> For example, if you substitute a plastic for steel, you might discover
> some property of steel you were relying on without knowing it. Your
> past experience may have told you steel worked well for such designs,
> but changing the material might tell you more of the reasons why it
> worked than just the reasons you assumed.
Agreed. Which says that if we wish to approach software construction
in the way I've described that we need to have _very good_ ways of
describing properties and maintaining these over years.
> Therefore, when you change the material, you have a new design, which
> may or may not work reliably the way the old design worked. This is
> very important in bridge design, because it takes decades to test a
> bridge. It's important to experiment with designs, but it's important
> to know you are doing so.
>
Agreed again. But I I would change the first use of the word "design"
to "system" (to make the implied analogy closer to software).
I would add that it appears to take decades to debug some software.
Another reason why it has to robust and reusable.
Jonah Thomas
Mellor) writes:
>e...@cinenet.net (Eric Smith) writes:
>> Steve Mellor <st...@projtech.com> wrote:
>> >designer. Do you want to be told "The requirement is steel" or do
>> >you want to the freedom to find the best material that meets the
>> >true requirements??
>> "Steel" is like a software package. That is, it's like a black box
>> with certain properties. You're saying you want to work with those
>> properties rather than with that black box. But the problem is that
>> there are too many properties to make it convenient to work with them
>> as a package unless you have a black box such as "steel".
>Thank you! Thank you for distinguishing between knowledge about the
>thing--in this example steel--and properties of the thing, in the
>example, density, stress, strain etc.
>And you have a good point: One name for the collection of _properties_
>could be "steel", but let's understand that this stands for "any
>steel-like substance" within constraints that you delineate later.
This just doesn't seem to be going away. <sigh> OK, I can't stand it
any more. You guys are talking as if steel was a thing, like a stack or
a buffer. "Steel" is a name for a bewildering variety of things with a
likewise bewildering variety of properties. It isn't uncommon for
designs to specify a particular type of steel -- when a variety of
others would do -- for simplicity, and also to make sure that a
contractor didn't slip in something else that was cheaper but marginal
with performance. (Inspection is necessary, too, but that's no help if
it wasn't specified in the first place.)
If software engineering involved buying modules from the lowest bidder
over a noisy communication line, and the primary backup for exception
handling after mutual good will was the American legal system, we'd
start seeing a lot of specs like "T4 will be used for all loadbearing
links."
Sean Case
>s...@zaphod.csci.unt.edu (Steve Tate) writes:
>>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
While we're at it, it's E.W. Dijkstra.
Sean Case
--
Sean Case g...@magna.com.au
Code is an illusion. Only assertions are real.
Dr. Rich Artym
g...@juicer.magna.com.au "Sean Case" writes:
> Code is an illusion. Only assertions are real.
Heh! It reminds me of a not-unrelated quip:
"The most reliable code is produced by compiling only the comments."
There's a moral in there somewhere just dying to get out ...
########### Dr. Rich Artym ================ PGP public key available
# galacta # Internet: ri...@galacta.demon.co.uk DNS 158.152.156.137
# ->demon # ri...@mail.g7exm[.uk].ampr.org DNS 44.131.164.1
# ->ampr # NTS/BBS : g7exm@gb7msw.#33.gbr.eu
# ->nexus # Fun : Unix, X, TCP/IP, OSI, kernel, O-O, C++, Soft/Eng
# ->NTS # More fun: Regional IP Coordinator Hertfordshire + N.London
########### Q'Quote : "Object type is a detail of its implementation."
A Murray Davidson
Jonah Thomas <JETh...@ix.netcom.com> wrote:
>In <1995Jul28....@projtech.com> st...@projtech.com (Steve
>Mellor) writes:
>
>>e...@cinenet.net (Eric Smith) writes:
>>> Steve Mellor <st...@projtech.com> wrote:
>>> >designer. Do you want to be told "The requirement is steel" or do
>>> >you want to the freedom to find the best material that meets the
>>> >true requirements??
>
>>> "Steel" is like a software package. That is, it's like a black box
>>> with certain properties. You're saying you want to work with those
>>> properties rather than with that black box. But the problem is that
>>> there are too many properties to make it convenient to work with them
>>> as a package unless you have a black box such as "steel".
>
>>Thank you! Thank you for distinguishing between knowledge about the
>>thing--in this example steel--and properties of the thing, in the
>>example, density, stress, strain etc.
>>And you have a good point: One name for the collection of _properties_
>>could be "steel", but let's understand that this stands for "any
>>steel-like substance" within constraints that you delineate later.
>
This seems to be one more example of muddling terminology between disciplines.
A component manufactured from (a) steel is a thing, steel itself is not.
Steel is a substance. In trying to stretch to an analogy with SE, one
might cast steel as the equivalent of the programming language from which
components can be crafted. But if you attempt to reason in this analogy
(changing material is equivalent to changing programming language) you'll
very rapidly get in a mess!
The repeated attempts to strain the analogies between civil or mechanical
engineering and SE keep foundering on this sort of misunderstanding.
>This just doesn't seem to be going away. <sigh> OK, I can't stand it
>any more. You guys are talking as if steel was a thing, like a stack or
>a buffer. "Steel" is a name for a bewildering variety of things with a
>likewise bewildering variety of properties. It isn't uncommon for
>designs to specify a particular type of steel -- when a variety of
>others would do -- for simplicity, and also to make sure that a
>contractor didn't slip in something else that was cheaper but marginal
>with performance. (Inspection is necessary, too, but that's no help if
>it wasn't specified in the first place.)
>
>If software engineering involved buying modules from the lowest bidder
>over a noisy communication line, and the primary backup for exception
>handling after mutual good will was the American legal system, we'd
>start seeing a lot of specs like "T4 will be used for all loadbearing
>links."
>
Quite right!
In mechanical engineering disciplines, much of the "analysis" phase can
neatly be avoided by adhering to approved codes and procedures. [Code
doesn't refer to computer programs but to codified methods etc.] A
designer will specify (e.g.) that pipework and pressurised systems must
conform to a particular ASME code in construction and inspection methods.
Similarly, welding and other construction procedures will be invoked.
The idea that the designer can supply annotated drawings invoking
designated materials and procedures and expect manufacturing to turn
out a correct and acceptable product (with inspection etc.) illustrates
the scale of the gap between mature engineering and SE - what would the
analogue look like in a software project?
Murray
--
--
Murray Davidson. YCV Section, ESTEC, Post Box 299, 2200 AG Noordwijk, NL
mur...@yc.estec.esa.nl Tel. +31 1719 84025 Fax +31 1719 12142
Frank Manning
Davidson) writes:
> In mechanical engineering disciplines, much of the "analysis" phase can
> neatly be avoided by adhering to approved codes and procedures. [Code
> doesn't refer to computer programs but to codified methods etc.] A
> designer will specify (e.g.) that pipework and pressurised systems must
> conform to a particular ASME code in construction and inspection methods.
> Similarly, welding and other construction procedures will be invoked.
>
> The idea that the designer can supply annotated drawings invoking
> designated materials and procedures and expect manufacturing to turn
> out a correct and acceptable product (with inspection etc.) illustrates
> the scale of the gap between mature engineering and SE - what would the
> analogue look like in a software project?
I'll take a stab at this.
Let me take a specific example. Let's say we want a new computerized
flight control system for an airplane. We have a requirement for
software that gets stored in various ROM chips in an embedded
computer, which flies the airplane.
Our programmers will have to conform to certain software development
"codes" or standards put forth by various organizations, including
our own. An example might be that goto's are prohibited. Another
might involve documentation standards.
Does this make the software analogous to your hardware example? The
answer is no, I believe, because half the "product" is missing. The
product in this case includes the embedded hardware. In order to make
a valid analogy, the hardware would have to include CPU, ROM/RAM
memory, I/O lines, signal conditioners and power supplies at a
minimum. You could perhaps argue that sensors and actuators are also
required.
The point is that the software is only half the answer. If all this
hardware is included, you now have the traditional codes to contend
with -- IEEE codes, Federal Aviation Administration requirement (in
America, anyway). ASME codes might be in there somewhere if you have
hydraulic actuators, for example.
The problem is that software, by itself, can't do anything. You have
to load it into real hardware before it can function. Once it's loaded,
you can't separate the software engineering from the electrical and
computer engineering, or even the aeronautical engineering in our
flight control example.
In my opinion, the confusion is due to the fuzzy definition of
software. Perhaps a program listing is to an executable program what a
mechanical drawing is to a piece of hardware. The listing describes
a pattern stored in a computer memory. A mechanical drawing is
similar to the listing in the sense that it describes something else.
It's a description of a thing, not the thing itself.
When you feed a program listing to a compiler, the compiler translates
it to a more convenient binary form, and the final executable is
"manufactured" by loading it into the memory of a physical computer.
In principle you could do the same thing with a mechanical drawing
stored as a CAD database.
With sufficient automation, a CAD database could guide a manufacturing
system to rearrange raw materials automatically, in the same sense that
a program listing guides a compiler/linker to rearrange a computer
memory automatically. (Someone with less discretion than me might be
tempted to bring up Star Trek replicators. But I won't.)
To get back to the original analogy, of course, the program listing
really should be combined with the annotated drawing of the computer
(at least) in order to unambiguously describe the total system. The
aforementioned codes would apply to the total system.
-- Frank Manning
Richard D. Wilson
engineer - Originally someone skilled in the assembly and operation of seige
engines. Later, someone skilled in the operation of of steam engine locomotives.
And so on...
Seriously, what is the difference between "applied science" and "engineering"?
Having been variously involved in materials science, physics, applied math, and
now software engineering I see no basis or need to distinguish between technical
diciplines on a categorical basis. If someone knows something, they know it. If
they dont't, thy don't. Regradless of whether they are calling themselves
"engineers", "scientists", "designers", etc.
Of course there are the academic distinctions (ie which department chair signs
one's diplomas and other such nonsense) between engineering disciplines and
sciences.
If engineering is NOT applied science, then what is it exactly?
--rwilson
Tim Dugan
Frank Manning <fr...@bigdog.engr.arizona.edu> wrote:
>In article <DCow...@yc.estec.esa.nl> mur...@yc.estec.esa.nl (A Murray
>Davidson) writes:
>
>> In mechanical engineering disciplines, much of the "analysis" phase can
>> neatly be avoided by adhering to approved codes and procedures. [Code
>>
>> The idea that the designer can supply annotated drawings [...]
>> the scale of the gap between mature engineering and SE - what would the
>> analogue look like in a software project?
>
>I'll take a stab at this.
>
>Let me take a specific example. Let's say we want a new computerized
>
>[...] half the "product" is missing. The
>product in this case includes the embedded hardware. [...]
>
>The point is that the software is only half the answer. [...]
While it's an important point that software is only part of the
system, I don't think this is answering the question. The question
had to do with writing a spec and getting back the product that
meets the spec.
We, in the software field, have NO standards about drawings to
represent software functionality.
>In my opinion, the confusion is due to the fuzzy definition of
>software. Perhaps a program listing is to an executable program what a
>mechanical drawing is to a piece of hardware. [...]
If that's the analogy you take, I think we are missing a significant
level of abstraction. We ought to be able to product a high-level
drawing much like a mechanical drawing and be able to objectively
say that the resulting piece of software meets that drawing spec.
As an industry, we can't.
>[...]
>In principle you could do the same thing with a mechanical drawing
>stored as a CAD database. [...]
Our equivalent of CAD is CASE. However, the transition from the
the CASE model to the actual code is not that great. Perhaps there
are exceptions, but this is in my opinion one of the weakest points
in the automation of software development.
In part, I think this is due to the incompleteness/immaturity of the
CASE drawings. CASE should combine a good modeling tool with sufficent
reuse libraries to generate significant software. I'm waiting for the
day...I wish I had a job where I could make that day arrive sooner! :)
---
When working on a NASA project, the management there wanted to use
a tool called MatrixX, a sort of CASE tool, to generate a lot of
software based on the MatrixX diagrams--it seemed to generate good
code, but primarilly for simulations, but the diagrams were
indecypherable to me...nothing like booch or rumbaugh...why is
this?
-t
--
Trephination: drilling a hole in the skull to
relieve pressure on the brain.
Michael R. Bastian
The biggest difference that I see between Software Engineering and other
Engineering discplines is that
the other Engineering disciplines are based on physics. There are laws that
must be obeyed and there are
formulas that describe those laws.
Software doesn't really have any fundamental laws, you can write code to do
whatever you want. The problem
that most developers have is that either the person implementing the project is
not the person who specified
and designed the project, and, hence interpret things differently because of
use of ambiguous notation. Another problem is that the people who analyze and
design the software make a lot of incorrect assumptions
about the system, the project, and the person who is implementing the project.
Finding the problems introduced by the incorrect assumptions and correcting the
problems and providing the correct assumptions
and documenting them are what Software Engineering is really about. It's not
about trying to draw software
so that people who devlop software can feel like engineers.
--
Michael R. Bastian
Interactive Software Systems Laboratory (ISSL)
E-Mail: bas...@issl.cs.byu.edu
Web: http://issl.cs.byu.edu/docs/Labbies/bastian/mike.html
Tim Dugan
Michael R. Bastian <bas...@issl.cs.byu.edu> wrote:
>ti...@Starbase.NeoSoft.COM (Tim Dugan) wrote:
>>
>[...]
>>
>>Our equivalent of CAD is CASE. However, the transition from the
>>the CASE model to the actual code is not that great. Perhaps there
>>are exceptions, but this is in my opinion one of the weakest points
>>in the automation of software development.
>>
>>In part, I think this is due to the incompleteness/immaturity of the
>>CASE drawings. CASE should combine a good modeling tool with sufficent
>>reuse libraries to generate significant software. I'm waiting for the
>>day...I wish I had a job where I could make that day arrive sooner! :)
>
>The biggest difference that I see between Software Engineering and other
>Engineering discplines is that
>the other Engineering disciplines are based on physics. There are laws that
>must be obeyed and there are
>formulas that describe those laws.
I don't know that that is strictly true. How is Industrial Engineering
based on physics? Also, there are lots of "laws" by which software
must abide, more "mathematical" than "physical" but still...
>[...] [A] problem
>that [many?] developers have is that either the [people] implementing
>the project [are] not the [people] who specified
>and designed the project,
Often, but not always. Couldn't say even if it were most of the time.
I've never been in this situtation. Not exactly. It's partially
perception.
>and, hence interpret things differently because of
>use of ambiguous notation.
That's pretty much what I said.
>Another problem is that the people who analyze and
>design the software make a lot of incorrect assumptions
>about the system, the project, and the [people] who [are]
>implementing the project.
Probably. This is not unique to software, though.
>Finding the problems introduced by the incorrect assumptions and correcting the
>problems and providing the correct assumptions
>and documenting them are what Software Engineering is really about.
I don't think I agree. What "Software Engineer" is "about" is producing
quality software systems for reasonable costs. That may include correcting
bad assumptions and writing documentation, but there is much more to it.
>It's not
>about trying to draw software
>so that people who devlop software can feel like engineers.
If you consider that there is an ultimate goal (a functioning system
built at reasonable cost and is maintainable), then you have to accept
that there are steps and/or phases necessary to reach that goal. It
makes sense to me that if you want a reliable, repeatable process,
the results of one step should be usable in a consistent fashion
in the next step. If the proceding step produces the software
equivalent of engineering drawings, then it makes sense that the
following step that makes use of these drawings be able to use
them effectively and relatively unambiguously.
Whether or not the people and/or machines that interprets them "feel
like engineers" is not that important...except that part of success
involves keeping your "engineers" happy.
Patrick D. Logan
>Software doesn't really have any fundamental laws, you can write code to do
>whatever you want...
But then some code will work better than others. So there must be some "laws"
guiding what works and what doesn't.
In the earlier days of civil engineering, people didn't know all their laws,
either. Mistakes were made and laws were discovered that worked.
Software is also in its early days, making mistakes, and learning about what
works and what doesn't.
Since software is a much broader and different domain than the "physical" applied
sciences, the laws of software may be more difficult to find.
The Patterns movement is one (yet broad) effort toward finding "laws" that work.
There is a long way to go, if it is possible at all.
--
mailto:Patrick...@ccm.jf.intel.com
Intel/Personal Conferencing Division
(503) 264-9309, FAX: (503) 264-3375
Tim
Patrick D. Logan <patrick...@ccm.jf.intel.com> wrote:
>"Michael R. Bastian" <bas...@issl.cs.byu.edu> wrote:
>
>>Software doesn't really have any fundamental laws, you can write code to do
>>whatever you want...
>
>But then some code will work better than others. So there must be some "laws"
>guiding what works and what doesn't.
I don't think it's a question of some absolute "laws" more so than a set
of consistent principles.
>In the earlier days of civil engineering, people didn't know all their laws,
>either. Mistakes were made and laws were discovered that worked.
Correct. And they were not necessarilly the only possible set of
"laws"...just one (or a few) that came about over time...
>Since software is a much broader and different
>domain than the "physical" applied
>sciences, the laws of software may be more difficult to find.
Well, who knows? It's not like we don't know a lot of them now.
>The Patterns movement is one (yet broad) effort toward finding "laws"
>that work. There is a long way to go, if it is possible at all.
Should I dare ask? What is the "Patterns movement"?
Dave Griffiths
>
>Since software is a much broader and different domain than the "physical" applied
>sciences, the laws of software may be more difficult to find.
>
>There is a long way to go, if it is possible at all.
I haven't read this Design Patterns book yet but was under the impression
that it was about finding... well design patterns, and then applying them.
Useful though that may be, it isn't a "law" because it depends on the
software engineer having the discipline to apply them. And this is the problem
with software. Self-discipline doesn't work. With the physical world, the
discipline and laws are imposed by the nature of the real world. In another
thread titled "Russian Dolls", I was wondering how we could create new
constraints on what is possible in software. Seems to me we have to learn
the lesson from success in engineering in the physical world and find ways
to _force_ programmers to structure applications.
Dave
David Cline
>The Patterns movement is one (yet broad) effort toward finding "laws"
>that work. There is a long way to go, if it is possible at all.
I see the Patterns movement more akin to compiling a collection
of popular recipes than to discoving the laws of cooking.
--
Dave Cline dcl...@netcom.com
Spring Valley Software
Jonah Thomas
<da...@prim.demon.co.uk> writes:
>I haven't read this Design Patterns book yet but was under the
>impression that it was about finding... well design patterns, and then
>applying them. Useful though that may be, it isn't a "law" because it
>depends on the software engineer having the discipline to apply them.
>And this is the problem with software. Self-discipline doesn't work.
It works for small projects, and for code that gets maintained by its
creator.
>With the physical world, the discipline and laws are imposed by the
>nature of the real world. In another thread titled "Russian Dolls", I
>was wondering how we could create new constraints on what is possible
>in software. Seems to me we have to learn the lesson from success in
>engineering in the physical world and find ways to _force_ programmers
>to structure applications.
Software construction is like a balloon. If you want more volume in
one place, you can constrict it somewhere else. Squeeze it down
everywhere except the area you want it to expand, and it will expand
into that area.
Until it pops.
(It would be good to find ways to use bigger balloons, that hold more
volume. If we could do that, we could put more one place without taking
it away somewhere else.)
Restricting what's possible gives people more chance to explore within
the realm of what's still possible. You get more chance for success
that way, provided the imposed constraints nicely match the problem
you're trying to solve. For a different problem, you need different
constraints.
If you constrain yourself into the arthropod body plan, you can make a
good lobster or crab. Lots of variations, the design is very reusable.
But none of them can swim like a fish or burrow like an earthworm or
catch crabs like an octopus or think like a human. Those take
different body plans.
We've already done a lot of this. Does your problem call for a
database? A spreadsheet? A word processor? Each of them limits
what's possible and lets users get tremendous results without advanced
programming techniques. But a database makes only a marginal
spreadsheet and a word processor makes a marginal database. Still, in
each case the user is _forced_ to accept the structure of the
application, and each successful application has at least a marginally
adequate structure to support users.
Scott A. Whitmire
>In article <3vtpck$p...@ornews.intel.com> "Patrick D. Logan" <patrick...@ccm.jf.intel.com> writes:
>>
>>The Patterns movement is one (yet broad) effort toward finding "laws" that work.
>>There is a long way to go, if it is possible at all.
>
>that it was about finding... well design patterns, and then applying them.
That's about as close as your going to get. It's akin to practices and techniques, not
immutable laws.
>Useful though that may be, it isn't a "law" because it depends on the
>software engineer having the discipline to apply them. And this is the problem
>with software. Self-discipline doesn't work. With the physical world, the
>discipline and laws are imposed by the nature of the real world. In another
That's not quite correct. The discipline came about during the early 1800s when briges
started falling out from under trains. The railroads were tired of losing those expensive
trains, and the public was tired of being put at risk. So, engineers started using a
more disciplined approach to engineering to avoid the CONSEQUENCES of failing to follow
the laws. The laws themselves were did not create the discipline - they were always there.
Before the disciplined approach, engineering wasn't exactly trial-and-error, it was more
take-what-has-worked-before-and-extend-it-a-little. When an extension worked, it became a
design practice. When it didn't work, we had a disaster on our hands. As late as 1940,
when "Galloping Girdie" sank in Washington State, we were still applying the take-what-has-
worked-and-extend-it-a-little. The builders of the Tacoma Narrows had been successful with
their first two projects (one of which was the Golden Gate). So, they tried to slim the
roadway down some more, and forgot to account for the airfoil effect of the roadway.
All of this is to say that software is not the only discipline with these "problems." And
that immutable laws do not force obeyance in and of themselves.
>thread titled "Russian Dolls", I was wondering how we could create new
>constraints on what is possible in software. Seems to me we have to learn
>the lesson from success in engineering in the physical world and find ways
>to _force_ programmers to structure applications.
>
The only way I can think of is to make the consequences of failure more direct and serious.
I don't think forcing engineers to use a particular method is the answer. They just need
to be made accountable for their results. Even in civil engineering, you can break the
rules, if your structure stands. If it fails, you have no defense - all of the
responsibility is yours.
Scott A. Whitmire sco...@advsysres.com
Advanced Systems Research
25238 127th Avenue SE tel:(206)631-7868
Kent Washington 98031 fax:(206)630-2238
Consultants in object-oriented development and software metrics.
Ari Juhani Huttunen
! In article <3vtpck$p...@ornews.intel.com> "Patrick D. Logan" <patrick...@ccm.jf.intel.com> writes:
! >The Patterns movement is one (yet broad) effort toward finding "laws" that work.
! >There is a long way to go, if it is possible at all.
! I haven't read this Design Patterns book yet but was under the impression
! that it was about finding... well design patterns, and then applying them.
! Useful though that may be, it isn't a "law" because it depends on the
! software engineer having the discipline to apply them.
A most awkward way to look at design patterns. Design patterns are no
rules that require discipline from the programmer. I've read the Design
Patterns book and I found patterns a rich source of new ideas that enrich
my designs. In no way can I see how they would constrain my designs.
! And this is the problem
! with software. Self-discipline doesn't work. With the physical world, the
! discipline and laws are imposed by the nature of the real world. In another
! thread titled "Russian Dolls", I was wondering how we could create new
! constraints on what is possible in software. Seems to me we have to learn
! the lesson from success in engineering in the physical world and find ways
! to _force_ programmers to structure applications.
Trying to force something down people's throats will fail.
--
--- --
-- -- Ari Huttunen ----
---- -- --
-- ----
--
Dave Griffiths
>
>Trying to force something down people's throats will fail.
We shall see. Strong typing forces something down people's throats and it
hasn't failed. Languages that force encapsulation down our throats haven't
failed. Some languages remove goto's and the freedom to jump where we like.
They haven't failed. Java takes the process a stage further and removes
structures and pointers - even less freedom to do what we want! Will it fail?
I don't think so.
Dave
Scott Wheeler
>...The [engineering] discipline came about during the early 1800s when
Um, your timing is a little out, and probably on the wrong continent.
There were no public trains in the early 1800s - the Stockton to
Darlington opened in 1825 and steam trains took a few years to reach
the colonies. However the physics and mathematics of bridges was
studied well before then, including some work by Newton (who built the
notorious wooden "Mathematical Bridge" at Cambridge, of which it is
said that during maintenance in the 1960's no-one could work out how to
put it back together without using some pegs). I am unsure of
systematic work before then, but it might be interesting to check
Vitruvius. Telford (builder of the Iron Bridge, in the late 18C) and
Brunel (Clifton suspension bridge, mid 19C) could also be interesting,
but I suspect proper analysis was only necessary for the latter.
Scott
Ari Juhani Huttunen
! In article <ARI.HUTTUNEN...@delta.hut.fi> Ari.Hu...@hut.fi (Ari Juhani Huttunen) writes:
! >
! >Trying to force something down people's throats will fail.
! We shall see. Strong typing forces something down people's throats and it
! hasn't failed. Languages that force encapsulation down our throats haven't
! failed. Some languages remove goto's and the freedom to jump where we like.
! They haven't failed.
Forcing something on someone includes the notion that the recipient
doesn't want the thing in question. I want the above things so the
examples fail. However, I would find it most annoying if someone told
me I had to do all my programming in Lisp. For someone else that might
be the idea of a heaven!
So I stay by my claim. You can only get people to accept things that
they want to accept. If you are a project manager and try to force something
on your programmers that they won't accept, they will eventually leave.
Usually the brightest ones will leave first. This doesn't mean that you
must abandon your idea. What it means is that you've got to get your
programmers to accept the idea and want the change.
! Java takes the process a stage further and removes
! structures and pointers - even less freedom to do what we want! Will it fail?
! I don't think so.
I hardly know Java and I don't claim it will fail. However, it's most
likely that Java will have no major impact on anything except WWW.
If language quality was the decisive factor, all C++ programmers would
convert to Sather by the hoardes. But we don't see that happening...
David Cline
While admitting that there is some dispute over the precise fraction,
Petroski (in To Engineer Is Human) quotes a figure of one in four for
the failure rate of 19th century iron railway bridges.
Luis Fernandes
> I hardly know Java and I don't claim it will fail. However,
> it's most likely that Java will have no major impact on
> anything except WWW.
Ah...but what impact do you forsee the WWW having on
"everything"... consider that the Hotjava Web-browser was written
entirely in java...
Bernard Robertson-Dunn
>In my opinion, the confusion is due to the fuzzy definition of
>software. Perhaps a program listing is to an executable program what a
>mechanical drawing is to a piece of hardware. [...]
There is a fundamental difference between a piece of hardware
which operates in the physical universe with a fixed set of laws and
software which operates in a conceptual universe where the laws are
not necessarily fixed or consistent.
Both software and hardware depend on their contexts in which to work.
The software context is arbitrary, the hardware context is constant.
regards
brd
Frank Manning
>> In my opinion, the confusion is due to the fuzzy definition of
>> software. Perhaps a program listing is to an executable program what a
>> mechanical drawing is to a piece of hardware. [...]
In article <40jmep$r...@fred.netinfo.com.au> Bernard Robertson-Dunn
<b...@netinfo.com.au> responds:
> There is a fundamental difference between a piece of hardware
> which operates in the physical universe with a fixed set of laws and
> software which operates in a conceptual universe where the laws are
> not necessarily fixed or consistent.
This is precisely the dilemma, and I think it's the major reason why
there is so much disagreement on the definition of "software engineer."
> Both software and hardware depend on their contexts in which to work.
Agreed.
> The software context is arbitrary, the hardware context is constant.
I see your point. On the other hand, once software gets loaded into the
memory of a physical computer and starts executing, it no longer exists
only in a conceptual universe. It's no longer arbitrary -- it has to
obey the same laws as the rest of the universe.
You could draw a similar analogy with a mechanical drawing -- the thing
it describes also exists only in a conceptual universe. Only when the
drawing gets translated into physical hardware does it exist in the
physical universe.
One reason software is considered different from hardware is that software
supposedly can't break. When a program hangs or crashes, it's not
considered broken because you can easily reload and restart.
On the other hand, if you smash a computer with a sledgehammer, it's easy
to see that the hardware is broken.
But wait a minute -- what happened to the program that was running on our
now-smashed computer? Isn't it as broken as the computer?
Granted, we can easily run a copy on another computer. But we've got
drawings of the smashed computer -- if we have a manufacturing system
that is sufficiently automated, we can re-create the computer just as
easily as we re-create the program. So what's the difference?
Perhaps the notion that software is unbreakable is an illusion caused by
the ease with which a program can be re-created. Suppose we have a
replicator that synthesizes our smashed computer as quickly and easily as
we reload a crashed program? Now what's the difference between hardware
and software?
I must confess that the end result of this line of reasoning is that
software can be patented just like hardware. Oh great. Now I'm depressed.
-- Frank Manning
Tim Dugan
>In article <40jmep$r...@fred.netinfo.com.au> Bernard Robertson-Dunn <b...@netinfo.com.au> writes:
>>
>>There is a fundamental difference between a piece of hardware
>>which operates in the physical universe with a fixed set of laws and
>>software which operates in a conceptual universe where the laws are
>>not necessarily fixed or consistent.
>
>work to, since they are completely defined. In the physical universe
>people have to discover the laws. In computing (and mathematics) we
>make them up (for software, this is the machine's instruction set, the
>OS calls, the language constructs and libraries, [...]
Well, I don't think the bulk of computing is reasoning about ISAs
(ie, Instruction Set Architectures), but more about interactions
between components with hopefully well-defined interfaces and
designing usable software and questions of portability, reuse,
efficiency, multi-user access, and on and on...there are "rules"
but they are hardly as smiple as 1+1.
-t
Andrew Edward White
>
>There is a fundamental difference between a piece of hardware
>which operates in the physical universe with a fixed set of laws and
>software which operates in a conceptual universe where the laws are
>not necessarily fixed or consistent.
On the contrary, the laws which govern software should be _easier_ to
work to, since they are completely defined. In the physical universe
people have to discover the laws. In computing (and mathematics) we
make them up (for software, this is the machine's instruction set, the
OS calls, the language constructs and libraries, ... - depending on
what level you are working at).
>Both software and hardware depend on their contexts in which to work.
>
>The software context is arbitrary, the hardware context is constant.
Yes, but I would rather total knowledge of an arbitrary system than
partial knowledge of a constant system.
(I have ignored hardware failure for the moment)
The real issue is how can we control for errors - human errors.
Are there design strategies that we can use? education? something else?
--
Andrew White
and...@cse.unsw.edu.au
URL: http://www.cse.unsw.edu.au/~andreww
"A complex problem is merely a simple hierarchy of simple problems"
C.W. Jones (Christopher)
says...
>
>In article <ARI.HUTTUNEN...@delta.hut.fi> Ari.Hu...@hut.fi
(Ari Juhani Huttunen) writes:
>>
>>Trying to force something down people's throats will fail.
>
haven't
like.
>structures and pointers - even less freedom to do what we want! Will it
fail?
>
I would be curious then to know why it is that one of the least typed,
least structured languages produced has for the most part become the
industry standard? Seems to go directly against the above ideas?
-cwjones-
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of the Microsoft Corporation.