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