Re: Who gets higher salary a Java Programmer or a C++ Programmer?
On Nov 27, 8:19 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Nov 27, 2:05 pm, LR <lr...@superlink.net> wrote:
Sabine Dinis Blochberger wrote:
The engineering part makes sure the software has been
tested for all possible (and impossible) events/usages.
I suspect that this is not even likely. I gave a counter
example else thread involving input for a number of boolean
variables, let's say 64. Tough to test all of those.
It's sufficient that it takes a double as input, and it is,
for all intents and purposes, impossible to test
exhaustively. People who claim the software is correct
because it passes some test suite aren't engineers. (Nor
are people who forego testing entirely, on the grounds that
it can't catch everything.)
Testing is one area where the analogies between software and
other engineering disciplines do stand up well. The software
developer who develops in the debugger poking in numbers and
checking the code "works" is little different form the
electronics engineer who tinkers on his bench with a signal
generator and an oscilloscope until his circuit "works". Both
are ill-disciplined, both are producing something fragile.
The equipment and time costs make it much more difficult for
the hardware engineer to build an test harness for his circuit
than for the software developer to write unit tests for his
code. The cost/time of testing problem increases
exponentially for larger physical systems which is why most
engineering disciplines now rely on simulation models.
There are similarities, but testing is not an option for all
disciplines. How do you "test" a skyscraper?
Maybe software development is closer to what engineering once
was: the basic application of scientific principals. We start
with an hypothesis (a requirement), we design and experiment
(write a test), conduct the experiment (run the test) and
observe the result.
We also use known (tested) components.
There is one other important difference (and the point was
raised earlier). Software isn't linear. Depending on what the
code does, this can affect the significance of testing.
I expect over time we will come to rely on more abstract tools
for software development (the simulation model approach used
by physical engineering disciplines), but that time is still a
way off.
Regretfully. Especially with regards to things like thread
safety; a good simulation model could determine the results of a
thread switch at all possible moments, something which is
impossible to trigger for a test.
And to repeat, I once spoke to a EE who told me his company
was going to test software for all possible inputs. Once I did
the arithmetic for him he withdrew his statement.
Just like they test their circuits with all possible inputs!
It's actually more or less possible for analog circuits. Just
feed a ramp into the input. But it doesn't mean much, because
such circuits may respond differently depending on input
frequencies, etc. Hardware isn't necessarily linear either.
(Back when I was working in hardware, we actually had a problem
where the resonant frequency of the backplane was about the same
as our main clock frequency. Most of the time, everything
worked fine, but as the components aged, their impedence changed
slightly, which changed the resonant frequency of the backplane.
When it corresponded exactly to the clock frequency, all hell
broke loose. And back then, the clock frequency was determined
by a simple RC oscillator, so a slight change in temperature,
and the thing started working again.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34