Re: Who gets higher salary a Java Programmer or a C++ Programmer?
On Nov 26, 10:32 pm, LR <lr...@superlink.net> wrote:
James Kanze wrote:
On Nov 26, 2:28 am, LR <lr...@superlink.net> wrote:
[...]
There is a certain personal satisfact to be had in
knowing that you've just delivered a program which
actually works.
Do the programs provably work?
To some degree.
In that case I think the answer is "no". Software is not
like a bridge.
Not entirely. It's generally easier to verify that software
will work than it is for a bridge, because software works in
a very controlled medium.
Yes, that's right. Programmers don't worry about things like
power outages. Although they may have to worry about
incomplete transactions. But the physical world is more or
less besides the point. Usually.
In a certain sense, by definition. The boundary with the
physical world is the boundary of what is usually considered
software. But of course, software isn't developed in a vacuum,
and someone will have to decide how to map the physical world to
the software's inputs and outputs. (As a simple, very low level
example: on most systems I've worked on, the hardware debounces
key contacts---on one, the hardware engineers weren't aware that
keys bounce, so we debounced them in software.)
[...]
I'm not exactly sure what problem you're referring to. If
I've understood you correctly, then no, software doesn't
have this problem. Which makes verification several orders
of magnitude easier; you know the full environment.
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. The parameters are
likely to be driven by budget, customer requirements or
perhaps good practice.
Well, you certainly hadn't made it plain, but that is, IMHO, a
critical element of engineering. Parameters driven by a number
of pragmatic constraints. In a similar way, well engineered
software will be in budget and on time. That's how you measure
the quality of engineering (along with meeting requirements, of
course). Good engineering delivers a product (in the largest
sense of the word) which meets the requirements, in budget and
on time, using rigorous (i.e. scientific) techniques which
ensure that this will be the case.
For some types of software, at laest. For real time
software, it's less obvious, since it's fairly hard to be
sure that you've analysed all possible timing issues.
I don't think testing all the possible interactions is
possible for most software. Consider a fairly simple program
that reads inputs for say 64 boolean variables and has at
least one conditional branch for each variable.
It depends on the software, but in general, yes. Testing can
only show that the software doesn't work, never that it works.
(But that's really true of just about every complicated system.
How do you test a bridge?)
And yes, I once did speak to a EE who told me that the
software his company wrote was fully tested for all possible
inputs.
It's possible for a small subset of software. An isupper
function for ASCII characters, for example.
But it's still several orders of magnitude easier than
verifying that you've analysed all possible physical
interactions which might affect a bridge.
But that isn't done. AFAIK ever. I don't think there's enough
time in the universe to do that. Not even for all the likely
cases.
No. In the end, designing bridges is just like creating
software. You can't test all possible cases. In the case of
bridge design, you can't even analyse all possible cases; you
can generally get a lot closer to it with software, but there's
still a costs-benefits trade-off involved. If the evaluation of
these trade-offs is done using a serious, scientific
methodology, we speak of good engineering. If it is done by
guessing, or not done at all, we speak of bad engineering (or no
engineering). Both for software or for bridges.
What kinds of metrics are used? Does software have a
stress point beyond which it will deform, like the metal
in the bridge will?
Seehttp://www.sei.cmu.edu/. I obviously can't stuff a
four year course in software engineering into a web
article.
No, I agree that would be difficult. I think I've visited
that site in the past. However, I've always thought that
Computer Science was a branch of Mathematics, and I've been
told by several engineers that engineering is the
application of scientific principle, so if you don't mind,
even though you can't do the full four years here, I was
wondering if you could take a shot at answering what I
think is a simple question with what might be a quick
answer: What scientific principle is being applied in
"software engineering"?
Mathematics.
Yeah, that's it then. Except math is not a science.
Of course it is. It's the queen of sciences.
And computer science is a science. Or are you going to claim
that computer science doesn't exist, too.
Seriously, engineering is a lot more than just the
application of scientific principles---engineering is also
concerned with esthetics, cost, development methodology,
etc. (Take a look at some of the bridges designed by
Gustave Eiffel---the viaduc de Garabit, for example---and
tell me that esthetics aren't involved).
I won't. But engineers aren't precluded from doing design, in
the sense of aesthetics rather then physics, are they?
My point is just that scientific principles are only a small
part of engineering.
Not always successfully though, the attempt to streamline
steam locomotives in the early to middle 20th century was a
bit misguided, wasn't it? At least from an engineering
standpoint.
That I don't know. Given the coefficient of penetration of a
typical steam engine, it would seem that almost anything would
help. But the real motivation was commercial, I think.
(Some of this raises several interesting questions that go
beyond the scope of this discussion. EG, I've read statements
by a few engineers who write something similar to: If it looks
right it will fly. Or steam, or sail, or whatever it is
they're designing for. I've heard programmers say something
similar. But then I'd expect cobblers and coopers to have
something similar to say. Why something looks right is left as
an exercise. ;) )
Personally, that DOESN'T sound like good engineering to me. But
the reverse might be true: if it is well designed, it will look
good.
And speaking of Eiffel and aesthetics let's not forget that
statue standing in NYC's harbor.
Which wasn't by Eiffel (although Eiffel's company did the
engineering for the internal structure to hold it up).
But the operative word in your case is "principles", not
just one principle, but more the set of all of them.
Oh I agree that there's more to engineering than the
application of scientific principle. But that is the heart of
the matter. Without that I don't think that it's engineering.
I'd prefer the expression "scientific method" to "scientific
principles". The word "principles" can be understood at too
many different levels.
In many ways, the way you develop software is exactly the
same as the way an engineer develops a bridge, or an
architect develops a building. It involves a complex
mixture of creative work, applying known and established
principles, having the work verified by others, etc., etc.
There is also the great range of applications: most
bridges/programs are really just a rehash of standard
solutions, and can be turned out quite quickly, with very
little real creativity or analysis. And a very, very few
push the envelope; these require even more analysis than
usual.
I agree that there are similarities. Even though you haven't
said it explicitly, I think there is quite a bit that software
developers can learn from engineers. But I don't quite see
how software development is engineering. I suspect they are
fundamentally different. I've sometimes wondered if perhaps
software development isn't little more like making movies.
I find software development to be very, very much like
architecture or bridge engineering (and probably a lot less like
chemical engineering---or even electrical engineering).
--
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