Goodbye, My Good Friend.

If they wrote the software correctly against the requirements, then there would be nothing to test.

How do you convince the customer that the software is written correctly
against the requirements? Especially given the experience most of us
have with software?

Jose
--
Quantum Mechanics is like this: God =does= play dice with the universe,
except there's no God, and there's no dice. And maybe there's no universe.
for Email, make the obvious change in the address.

Jose wrote:

If they wrote the software correctly against the requirements, then
there would be nothing to test.


How do you convince the customer that the software is written correctly
against the requirements? Especially given the experience most of us
have with software?

You can't, I was being facetious. Since the OP writes software, I knew
he'd understand.

However, he also understands that only a very, very naive customer
believes that the tests you show them ensures that the software is
written correctly against the requirements.

Software development is still progressing, albeit glacially, but we have
a long ways to go. As long as the s/w community insists on using
substandard tools such as C++ and such, things will progress slowly.


Matt

On Mon, 15 Aug 2005 10:38:09 GMT, Matt Whiting
wrote:

snip here and there,

You can't, I was being facetious. Since the OP writes software, I knew
he'd understand.

However, he also understands that only a very, very naive customer
believes that the tests you show them ensures that the software is
written correctly against the requirements.

Software development is still progressing, albeit glacially, but we have
a long ways to go. As long as the s/w community insists on using
substandard tools such as C++ and such, things will progress slowly.


Matt

Now you've really really got my interest.

Substandard?

What is standard? I really do want to improve on C++, but I haven't
seen anything better.

Please don't say Ada.

Mike Weller

"Mike Weller" wrote in message
news:1124124085.7f7946b83a82b2e392e47822e8419de4@o nlynews...
Software development is still progressing, albeit glacially, but we have
a long ways to go. As long as the s/w community insists on using
substandard tools such as C++ and such, things will progress slowly.


Matt

Now you've really really got my interest.

Substandard?

What is standard? I really do want to improve on C++, but I haven't
seen anything better.

(getting sucked into an off-topic thread...)

I think he's talking about the fact that development tools still allow
programmers to do stupid things. For example, Java and C# add a layer of
protection, making it more difficult for programmers to screw things up.
They are still procedural languages, and it may be that programming really
needs a whole paradigm shift to some other sort of programming. Charles
Simonyi was pushing something he was calling "intentional programming" a
while back...so far, nothing real has come of that, but the general thought
that getting a little further from the underlying Turing machine may reduce
mistakes is still valid, IMHO.

That said, most of the problems with programming stem from how careless
people are while doing it. As a programmer myself, I am well aware of the
difference between well-written code and poorly-written code. Most code is
poorly-written, IMHO. This is true through all phases of implementation,
from the original design and architecture, through the actual coding, and
finally with respect to testing, both on the part of the programmer as well
as on the quality assurance folks, should they actually exist.

For the most part, engineering in other technical areas tries to take into
account human error. Structures are built with some margin of extra
strength, machinery attempts to include designs that help prevent the user
from killing themselves, etc. Programming, on the other hand, still pretty
much lets the programmer do whatever dumb thing they want. Protected memory
operating systems (ie, pretty much every operating system in common use
today) do help prevent one bad programmer from messing up someone else's
stuff. But even there, a given application is not protected from itself,
and certain components of the operating system can still bring the whole
mess down (audio and video drivers being a common culprit).

At some point, perhaps programming WILL develop better tools, and maybe even
more stringent standards of quality. I saw an ultrasound machine at the
hospital crash the other day; during a routine exam, this wasn't a problem,
but what if it had been being used during some kind of invasive procedure
(ultrasound-guided fine-needle aspirate, for example). And no, the
ultrasound machine wasn't running Windows (or any other off-the-shelf
operating system). The more pervasive computers become, the more important
it will be to hold programmers to higher standards.

Until then, they are going to keep making the same stupid mistakes every
other careless human being does on a daily basis. And there are a LOT of
careless human beings.

Please note, the above is a broad oversimplification of the issues at hand.
This is the sort of thing that a professional committee could spend a year
talking about and still not come up with a good answer. Pretty hard to sum
up in a single Usenet post, even a long one.

Pete

On Mon, 15 Aug 2005 11:33:15 -0700, "Peter Duniho"
wrote:


(getting sucked into an off-topic thread...)

I don't think so. Computers have become such an important part of
flying that we need to address them as much as aerodynamics. Air
Traffic Control, navigation, flight planning, and to a growing extent
our engine controls, are members of that domain.


I think he's talking about the fact that development tools still allow
programmers to do stupid things.

So does the mechanic that forgot to check the last oil line on my
favorite 210. Forced landing and a ruined brand new TSIO-520.

For example, Java and C# add a layer of
protection, making it more difficult for programmers to screw things up.

I tried for years to sell a product called the Input/Output
Requirements Language. In theory it would produce the final code from
the requirement's visual and textual description.

They are still procedural languages, and it may be that programming really
needs a whole paradigm shift to some other sort of programming. Charles
Simonyi was pushing something he was calling "intentional programming" a
while back...so far, nothing real has come of that, but the general thought
that getting a little further from the underlying Turing machine may reduce
mistakes is still valid, IMHO.

I'm not so sure. To me, as a developer, I think that de-humanizing is
the worst solution. Counting lines of code produced per hour is a
good example. We need to get back to individual responsibility for
quality control. And more importantly, individual input for finding
design flaws and their correction. It worked well for NASA in the
1960s. Have we abandonded that work ethic?

That said, most of the problems with programming stem from how careless
people are while doing it. As a programmer myself, I am well aware of the
difference between well-written code and poorly-written code.

I'm a brute force programmer myself. My stuff works.

Most code is
poorly-written, IMHO. This is true through all phases of implementation,
from the original design and architecture, through the actual coding, and
finally with respect to testing, both on the part of the programmer as well
as on the quality assurance folks, should they actually exist.


One of the hardest things that I've done is customer acceptance.
Despite all of the meetings and testing, there is no way we can seem
to just let the system work. There is always something more to do.
That is the point where I would dearly love to start over again with
the latest technology and "do it right".

For the most part, engineering in other technical areas tries to take into
account human error. Structures are built with some margin of extra
strength, machinery attempts to include designs that help prevent the user
from killing themselves, etc. Programming, on the other hand, still pretty
much lets the programmer do whatever dumb thing they want. Protected memory
operating systems (ie, pretty much every operating system in common use
today) do help prevent one bad programmer from messing up someone else's
stuff. But even there, a given application is not protected from itself,
and certain components of the operating system can still bring the whole
mess down (audio and video drivers being a common culprit).


Those are tangible and measurable. With computers it's more like the
fad a few years ago with artificial intellegence. A friend who
studied that at the Phd level explained that the goal was like
defining artificial masculinity. He also looked at genetic
engineering and asked, "What if you changed one line of code in the
most complex program ever written?"

At some point, perhaps programming WILL develop better tools, and maybe even
more stringent standards of quality. I saw an ultrasound machine at the
hospital crash the other day; during a routine exam, this wasn't a problem,
but what if it had been being used during some kind of invasive procedure
(ultrasound-guided fine-needle aspirate, for example). And no, the
ultrasound machine wasn't running Windows (or any other off-the-shelf
operating system). The more pervasive computers become, the more important
it will be to hold programmers to higher standards.


Yes, and that gets back to the individual.

Until then, they are going to keep making the same stupid mistakes every
other careless human being does on a daily basis. And there are a LOT of
careless human beings.


We're human. Thank God. Or at least the incredibly long string of
random events that put us here.

Please note, the above is a broad oversimplification of the issues at hand.
This is the sort of thing that a professional committee could spend a year
talking about and still not come up with a good answer. Pretty hard to sum
up in a single Usenet post, even a long one.

Pete


Mike Weller

Mike Weller wrote:
On Mon, 15 Aug 2005 10:38:09 GMT, Matt Whiting
wrote:

snip here and there,


You can't, I was being facetious. Since the OP writes software, I knew
he'd understand.

However, he also understands that only a very, very naive customer
believes that the tests you show them ensures that the software is
written correctly against the requirements.

Software development is still progressing, albeit glacially, but we have
a long ways to go. As long as the s/w community insists on using
substandard tools such as C++ and such, things will progress slowly.


Matt


Now you've really really got my interest.

Substandard?

What is standard? I really do want to improve on C++, but I haven't
seen anything better.

Please don't say Ada.

Ada is better from a reliability and correctness perspective. So is
Java. However, I think that longer term model-based development tools
show the greatest promise.

Matt

Matt Whiting wrote:
Ada is better from a reliability and correctness perspective. So is
Java.

I disagree... You can write crap code in ANY language... I've worked on
Ada and Java projects... Although I have more confidence in Ada than
Java, neither are what I would call "confidence inspiring"... Although
C++ has some nice features, I prefer to stick with straight 'C' from a
portability standpoint... With a statically linked executable, I can
have a pretty good feeling that my executable is going to run the same
each time it is executed... With DLLs and such, this is not possible,
so I avoid them... Unfortunately, sometimes it's difficult to
completely avoide them when you're forced to program for Windoze
platforms...

However, I think that longer term model-based development tools
show the greatest promise.

And, exactly WHAT have you been inhaling?

rant-mode
The problem that I see these days is that the 'developers' no longer
have to design an entire system... MS has ushered in the age of
fill-in-the-blank programming... These 'developers' draw their user
interface dialogs and how they relate to each other and then all they
have to do is fill in the pieces of code for the various callback
functions...
/rant-mode