Who gets higher salary a Java Programmer or a C++ Programmer?

[Matthias Buelow]

Because it makes it a structured, systematic and quantifiable approach
(see link above). Instead of just guessing use cases, results and
timelines.

You can only do this if you are writing software that basically is made
up of subparts that have been done before. This doesn't work for all
software. If you've never built something like a bridge before, you
can't apply proven patterns and procedures.

 

[Lew]

Interesting stuff. I've heard about that first usage in a NATO paper.
I read somewhere, sorry, no cite [sic], that the intent of the usage was to shock.

More unsubstantiable hearsay from someone who rejects all actual evidence on
the basis of anecdotal, non-verifiable junk like this.

For example, I think
the use of timber in bridges wasn't even reasonably understood until
Herman Haupt did the experiments to figure out what the strength of the
beams were.

The ancient Romans had a very reasonable understanding of the structural
strength of timber and other materials that they used in bridges.

 

[Alexander Grigoriev]

The problem with a program provability that in real life, you only can
formulate complete requirements for small pieces of it. Like for a sort
algorithm, for some calculation, etc, etc. When you start to formulate usage
scenarios for an OS or interactive application, it's not quite possible to
write them down in a form that would be useful for formal proof. Modern
software operates in an environment so indeterministic and chaotic (its
input ispretty much white noise), that one would have very hard time trying
to mathematically prove that a program will do as specified.

I'm sorry, I'm not sure what you're saying in context. Are
you suggesting that there's some way to distinguish between
programs that can be proven to halt and those that it can't be
proven for?

He's saying that for a given set of requirements, you can write
a program which provably meets those requirements. Whether
"halting" is part of those requirements or not---if halting is
part of the requirements, then you write the program in a way
that it can be proved to halt.

Of course, unless provable halting (or anything else) is part of
the unnegociable requirements, it might be poor engineering to
do so. Engineering is a lot about finding cost-efficient
solutions (as opposed to pure science, where cost is not a
factor).

 

[Alexander Grigoriev]

If programming were mathematics, then it would be possible to derive new
programs from existing ones. We would have no buggy software, because the
smallest "axiom" programs would be correct, and everything else would be
rigorously derived from them.

That's caled code reuse. It helps to reduce bugs, too.

 

[Lew]

You have a definition that you invented, claim by hearsay only that you have
"taken [it] from various engineers [you] know", none named and whose expertise
cannot be verified, and who may, for all you tell us, have told you additional
aspects that you choose to omit from this discussion, and which you refuse to
modify in the face of widely-accepted definitions proffered by official bodies
of certified, professional engineers who are cited by verifiable reference.

You are intellectually dishonest.

Which is only part of it. Quantum physics applies scientific
principles, but I wouldn't consider it engineering.

This discussion has given overwhelming evidence that software engineering as a
discipline does exist, that it has a definition or set of definitions that is
widely accepted by engineers and high-end academic institutions, that it has a
different definition than that proffered by the troll, and that it is widely
practiced. The troll will never accept this evidence, choosing instead to
circularly define "software engineering" in an idiolectic, self-serving and
circular fashion, retreating to mere repetition of his discredited arguments
whenever confronted with the facts.

 

[Lew]

But i'm right in thinking that one doesn't need either of those to call
oneself a software engineer, i hope?

Absolutely.

 

[Martin Gregorie]

I'm sorry, but what is quite wrong? I completely fail to understand how
your response contradicts anything I wrote above. Please explain,
because I utterly bewildered by your response.

This:
"But I think I made it plain that engineers don't consider the entire
physics of the bridge. They might not consider fluid interactions or
wind loading or some such."

I suggest you do some reading about those bridges.

 

[Matthias Buelow]

And wrong. Software development can be, and is, an engineering discipline.

You can reduce it to that, however, you'll lose out in the long run.

Writing software isn't like building a bridge. Once a bridge is in
place, it will stay that way for a long time. Apart from maintenance, it
most likely won't be touched. It certainly won't be turned into an
apartment block.
However, this is what happens to software. A large program is a moving
target. It needs to be able to grow, expand and mutate far beyond what
has been imagined by its original designers. Also, it is impossible to
make perfect and totally reliable software. You can make a bridge that
won't fall down if you correctly calculate all the statics, make sure
the building work isn't executed sloppily with subgrade materials and
include a generous safety margin in all areas. Software is far too
complex for that. Software must be able to fail gracefully, and recover
from that. It must be possible to, if needed, debug and modify (running)
software, and large software systems also have to include heuristical
and autonomous mechanisms for self-repair. The notion that software
reliability comes from meticulous up-front "engineering" is naive thinking.

 

[Lew]

You can reduce it to that, however, you'll lose out in the long run.

How is that in any way a reduction?

Writing software isn't like building a bridge. Once a bridge is in
place, it will stay that way for a long time. Apart from maintenance, it
most likely won't be touched. It certainly won't be turned into an
apartment block.

What does that have to do with software being an engineering discipline?

However, this is what happens to software. A large program is a moving
target. It needs to be able to grow, expand and mutate far beyond what
has been imagined by its original designers. Also, it is impossible to
make perfect and totally reliable software. You can make a bridge that
won't fall down if you correctly calculate all the statics, make sure
the building work isn't executed sloppily with subgrade materials and
include a generous safety margin in all areas. Software is far too
complex for that. Software must be able to fail gracefully, and recover
from that. It must be possible to, if needed, debug and modify (running)
software, and large software systems also have to include heuristical
and autonomous mechanisms for self-repair. The notion that software
reliability comes from meticulous up-front "engineering" is naive thinking.

Nothing you said contradicts the notion that software can or should be
engineered. /Au contraire/ you have presented compelling arguments for why
software must be engineered. Given the dynamic nature of software, solid and
competent engineering must be employed to make it viable and robust.

In this, software engineering is more similar to civil engineering than bridge
building. Cities also must live, grow, change, evolve and repair themselves
in the face of chaotically induced change. No one can plan a city "up front"
either.

Is it possible to make a "perfect and totally reliable" city plan? No? Does
that invalidate civil engineering as a discipline? Certainly not.

Also, introducing the thought that engineering must be done "up front" is a
straw man argument. Nothing about engineering says it must be done strictly
/a priori/ in any engineering discipline. Even bridges need maintenance and
repair over their lifetimes, and good bridge engineering accounts for that.
Thinking that engineering is strictly up front is the naive thinking.

The distinction is that engineering is appropriate to the domain of activity.
Bridges are not just like software, so the respective engineering
disciplines will differ as well. This does not invalidate either profession
as an engineering one.

 

[Bent C Dalager]

Also, introducing the thought that engineering must be done "up front" is a
straw man argument.

Anyone who thinks that the engineering of buildings is a strictly
up-front process should try to track down an iron worker (the sort of
people that end up /actually/ putting these things together) and ask
him how well he thinks that would work out in practice

For any non-trivial engineering project, much of the engineering takes
place throughout the construction phase as real-world limitations make
their presence known. Only recently have solutions become available
that would give the up-front planners any reasonable idea about how
pipes and ducts can actually be laid out in a building, for instance.

See any of the "Construction" type docutainment series on Discovery et
al to get an idea of the prevalence of this and keep in mind that what
the docutainment dramatizes as the end of the world and probable death
knell of the project (that is, some unplanned-for change during
construction) is actually pretty common and undramatic and usually
gets promptly handled by the engineers.

Cheers,
Bent "oh, and I changed the subject" D

 

[Ian Collins]

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.

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 (writ a test), conduct the
experiment (run the test) and observe the result.

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.

Just like they test their circuits with all possible inputs!

 

[Martin Gregorie]

But i'm right in thinking that one doesn't need either of those to call
oneself a software engineer, i hope?

In theory, no. However, in practise it can be helpful when you consider
some of the cowboys I've met on big contracts and the dodgy agencies they
worked through.

A long time ago in Bath I was amongst 80 contractors fixing a wee problem
the MoD had found themselves saddled with. There was one guy there who
other contractors had seen on and around various projects for 6 or 7
years and had never been known to successfully finish a program. He
always managed to leave in time and his programs were generally scrapped
and rewritten. Example: he didn't know that by default a COBOL program
drops through to the next paragraph, so his source looked like this:

.....
PARA-1.
DO THIS.
DO THAT
PERFORM SOMETHING-OR-OTHER.
GO TO PARA-2.
PARA-2.
.....

The agency he worked through was as bent as he was incompetent, once
supplying another coder as having 3.5 years of ICL 1900 COBOL when in
fact he had been a 1900 operator for 3 years followed by a 6 month COBOL
course.

Checking on recognised qualifications could certainly have saved a lot of
programming shops a lot of grief and expense over the years with people
like this around.

 

[Tom Anderson]

This:
"But I think I made it plain that engineers don't consider the entire
physics of the bridge. They might not consider fluid interactions or
wind loading or some such."

I suggest you do some reading about those bridges.

Hold up - those examples show that, in the cases of those bridges (or
Tacoma Narrows, at least), the engineers indeed did not consider wind
loading!

tom

 

[Tom Anderson]

In theory, no. However, in practise it can be helpful when you consider
some of the cowboys I've met on big contracts and the dodgy agencies they
worked through.

A long time ago in Bath I was amongst 80 contractors fixing a wee problem
the MoD had found themselves saddled with. There was one guy there who
other contractors had seen on and around various projects for 6 or 7
years and had never been known to successfully finish a program. He
always managed to leave in time and his programs were generally scrapped
and rewritten. Example: he didn't know that by default a COBOL program
drops through to the next paragraph, so his source looked like this:

.....
PARA-1.
DO THIS.
DO THAT
PERFORM SOMETHING-OR-OTHER.
GO TO PARA-2.
PARA-2.
.....

The agency he worked through was as bent as he was incompetent, once
supplying another coder as having 3.5 years of ICL 1900 COBOL when in
fact he had been a 1900 operator for 3 years followed by a 6 month COBOL
course.

Checking on recognised qualifications could certainly have saved a lot
of programming shops a lot of grief and expense over the years with
people like this around.

Oh, absolutely. I'm not knocking the value of qualifications! At least,
not all of them. I was just wondering if my lack of them made me a
criminal.

tom

 

[James Kanze]

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.

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.)

 

[Tom Anderson]

I think there are, otherwise we would still program in machine code. I
think for example functions, computer languages, libraries, processes,
operating systems are all some kind of generalisations aka approximations
which allow us to reason about this bit-twiddling machine in more
convenient terms.

That's an interesting idea. The trouble is that those abstractions are
mostly either too complicated to work or too simple to be any use. Your
example of an operating system is quite a good one - we can have a very
simple formal model of how something like memory management works, which
lets us think about programs running in a simple linear address space,
despite the truth being rather different. But i don't think you can break
a typical application down into bits like that. The interfaces between
parts, and the behaviours of those parts, are too complicated to be
described simply.

This is why designing really successful component architectures has been
so hard (so far, impossible). Components - for reuse or for proof - need
to have simple interfaces. The interfaces to interesting bits of code just
aren't simple.

tom

 

[Martin Gregorie]

Oh, absolutely. I'm not knocking the value of qualifications! At least,
not all of them. I was just wondering if my lack of them made me a
criminal.

Why on earth would it do that?

We're not yet /required/ to belong to a professional association like
medical doctors.

 

[Martin Gregorie]

Hold up - those examples show that, in the cases of those bridges (or
Tacoma Narrows, at least), the engineers indeed did not consider wind
loading!

Exactly so. Look back up this post and you'll see that "LR" said it
didn't matter whether bridge designers looked at wind loading or not
because the cost of doing the design was a bigger consideration than
spending time and money to calculate wind loading. I pointed to two well-
known failures that were due to the designers ignoring wing factors. He
evidently *didn't know* that both blew down because he clearly didn't
understand that reply.

You jumped in when I was trying, rather politely I thought, to give "LR"
the chance to dig himself out of his self-constructed hole rather than
calling him a pig-headed know-nothing. So I won't, but I did want to see
what his reply would be.

 

[Arne Vajhøj]

You can reduce it to that, however, you'll lose out in the long run.

Writing software isn't like building a bridge. Once a bridge is in
place, it will stay that way for a long time. Apart from maintenance, it
most likely won't be touched. It certainly won't be turned into an
apartment block.
However, this is what happens to software. A large program is a moving
target. It needs to be able to grow, expand and mutate far beyond what
has been imagined by its original designers.

I think everyone agrees that software engineering is much more complex
than bridge building.

But that does not make it less engineering - probably more.

Also, it is impossible to
make perfect and totally reliable software.

Not true.

It just happens that the cost for doing that is too high.

The notion that software
reliability comes from meticulous up-front "engineering" is naive thinking.

It is the only place software reliability can come from.

Arne

 

[Arne Vajhøj]

You can only do this if you are writing software that basically is made
up of subparts that have been done before. This doesn't work for all
software. If you've never built something like a bridge before, you
can't apply proven patterns and procedures.

But that is the same for software and bridges.

Arne