Post by Nick Maclaren|>
|>
|> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
|>
|> "a single domestic passenger airplane alone can contain as many as 6
|> million parts"
|>
|> http://www.majorprojects.org/pubdoc/677.pdf
|>
|> " Aircraft carrier project--a naval project with 30 million parts (a
|> submarine has only 8 million parts)."
|>
|> Why would software be any harder?
Because it is less well engineered.
If by less well engineered you mean that most software never goes
through a design, specification, and test process anything like
something built for the military or intended for civilian flight, I
agree with you, but there is nothing fundamental about software that
dictates that it be built that way.
Post by Nick MaclarenAlso, do you know how many
such military engineering systems have significant and even major
components that are decommissioned before they are got to work in
the field?
If you take a subscription to Aviation Week you can follow at least
some of the misadventures of aerospace engineering projects in real
time.
The American aerospace industry has been repeatedly belittled, at
least in the American press, as being this inept sinkhole for money.
Even a sympathetic insider, after having sat through just a few
interminable meetings, might wonder how anything ever gets done.
The reality is that the industry has acquired an astonishing mastery
of complexity and an ability to marshall heterogeneous resources from
the most unlikely places to bring about sometimes quite amazing
results.
For all its reputation for coverups, aerospace has been incredibly
unsuccessful in hiding its screwups. The spectacular successes, on
the other hand, are often concealed from public view under pain of a
prison sentence.
Post by Nick Maclaren|> A paradigm already exists for scaling programs to arbitrarily large
|> sizes. It's called a network.
Yeah, right. I was having run-ins with the "structured programming"
dogmatists back in the 1960s and 1970s on this one, and the common
errors have not changed.
By splitting programs into functions of at most 20 lines long (yes,
seriously), you may be able to understand every function at a glance.
You will not, however, be able to understand their interactions. So
you split the program into separate ones of at most 20 functions,
and can now understand every program. But you will not be able to
understand the network of programs. And so on.
The same thing applies to hardware. It is easy to analyse and debug
race and other inconsistency conditions involving two entities. As
networks grow in complexity, it becomes harder and harder. There
comes a point (approaching, in some networks) where most failure
time (down time or debugging) is not associated with a problem in
ANY component, but is associated with the network structure itself.
TANSTAFFL.
I believe in lots of things most other people don't, including magic
and free lunches. The internet works. Bank ATM networks work. The
global financial system works. The telephone system works.
Post by Nick MaclarenPost by Robert Myers" Aircraft carrier project--a naval project with 30 million parts (a
submarine has only 8 million parts)."
Why would software be any harder?
Because people insist on designing it in a strongly-coupled way.
If the eyes of students don't roll heavenward when they are presented
with a network stack, told how useful the concept is, and then watch
how actual software breaks the layering model right from the git-go,
they don't belong in engineering.
I deliberately did *not* choose some common term from software
engineering, like structured programming or object oriented
programming.
A network is such a powerful paradigm for software design because each
node has a finite number of ports. Like an ancient walled city, all
information must come in or go out through the gates. Each city is
governed separately. Requests for information go out through a gate
(and can be logged completely if necessary) and responses go out
through a gate (and can be logged completely if necessary). The
communication protocal is transparent and communication traffic can be
intercepted outside the city gates, so that no principality's word has
to be taken for it as to what it is saying to the other principalities
or what it is hearing from other principalities.
When the number of city-states becomes unmanageable, nations form. If
their borders are porous, it is not intentional. Defining actual
nations without randomly porous borders is impossible, but in the case
of software, it is not. When nations become too large, you form
confederations of nations. At every level of governance the rules are
the same: each principality manages its own internal affairs,
communicates with the outside world only through a finite number of
ports, and uses a communication protocol that can be intercepted an
deciphered by an authorized examiner of network traffic outside the
city walls.
By some no very great stretch of the imagination, the internet is just
one big program. By a slightly smaller stretch of the imagination, my
humble intranet is a program, and a very complicated one, at that. By
no stretch of the imagination at all, very complicated programs
designed, written, and supervised by independent parties can cooperate
over a far-flung network to perform a single a task in a way that is
no different from a "Hello, World" program.
As to "emergent behavior". Yes, such things happen. That's how
systems engineers stay employed. :-).
Post by Nick MaclarenHave you ever tried to report a problem to a large vendor that is
due SOLELY to the underlying computational assumptions of three or
more separately developed components being subtly incompatible?
I have. Guess how far I got.
When an aerospace contractor buys anything other than services, there
is a specification. There are even specifications for specifications.
All questions of culpability for subcontractors come down to one
question: did the subcontractor deliver parts that meet the agreed to
specification, or not. The general contractor is responsible for
selecting and coordinating subcontractors in such a way that the
overall system works. If all subcontractors have delivered according
to spec, it is the general contractors' job to fix it. That's why
they get the big bucks.
If you've bought software and/or hardware from a general contractor,
you almost certainly bought a support contract with it. If your
vendor isn't meeting the terms of the support contract and you are
having a hard time enforcing them, you have my sympathy, with no trace
of sarcasm. Huge companies in this business have survived very hard
times by going to great lengths to avoid leaving their customers
feeling that way.
RM