Stonemasons and Coders

From: Nick Landsberg (SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net)
Date: 07/04/04 

Date: Sun, 04 Jul 2004 05:15:48 GMT

Edward G. Nilges wrote:

> Nick Landsberg <SPAMhukolauTRAP@SPAMworldnetTRAP.att.net> wrote in message news:<fOpFc.181315$Gx4.158477@bgtnsc04-news.ops.worldnet.att.net>...
>
>>Edward G. Nilges wrote:
>>
>>I am only going to reply to one particular aspect of
>>this post and snip the rest - NPL
>>
>>[ MUCH SNIPPAGE ]
>>
>>
>>>Why do they call it computer "science" in the first place? Because
>>>it's more than engineering and more than science.
>>>
>>
>>I would disagree with that opinion. (Your opinion vs.
>>my opinion? OK... that's what debates are all about.)
>
>
> No, that's not what debates are all about. In fact, debates are about
> at a minimum swaying an audience that is uncommitted either way and in
> certain cases even bringing one's opponent over to one's side. Debates
> aren't about "opinion" but about TRUTH.
>
> But not even a majority of the audience must be swayed: at a minimum
> one reaches out to one or two soulmates in the audience. As to the
> rest, when they get it, they will get it.
>
> This is NOT about "expressing one's opinion".

Since I do not believe that I know the
"one true way," I am willing to be swayed
by sound reasoning which is backed up by
verifiable data.

I don't give a crap about the audience,
and I'm very stubborn.

>
>
>>Designing a structure, or a mechanical device, to
>>perform a particular task is (now) a well known
>>discipline. It's called "engineering."
>>
>>It was not so hundreds of years ago.
>>
>>For example, the method of building Gothic
>>Cathedrals in the middle ages was to build
>>one section of the structure during the summer,
>>wait for winter, and see if the winter winds
>>blew it down. (That is, a whole 20 meter wide
>>section was built to it's ultimate height,
>>rather than all the sections being built to
>>a 5 meter height this year, and to
>>10 meters next year, etc. This has been likened
>>to saying that Gothic Cathedrals "were not
>>built from the ground up.")
>>
>>BTW: flying buttresses were partially
>>invented to shore up the structures from the wind
>>forces, and the gargoyles on top were actually
>>fantastically carved counterweights to keep the
>>stacked stones in place.
>>
>
> This is something which I find hard to credit. Stonemasons then and
> now have in fact the ability to construct structures that stay up.
>
> Notre Dame and Chartres have "stayed up" for hundreds of years.

My original degrees were in engineering. I made a hobby
of studying the building techniques of the middle
ages. (And that was before the internet, so I had to
do some pretty heavy research in my "hobby time" to
dig this stuff up.)

It is one thing for a journeyman stonemanson to
put up a one story structure. It is quite another
to put up a 40-50 meter tall structure such as the
cathedrals. If the stonemason had never built that
high a structure, it was his "best guess" as to how
much weight would be necessary on the windward side
to counterbalance the wind forces which tend to cause
tension on the windward side. Since Catedral
construction was often a lifetime job, or sometimes
two lifetimes, this was not usually something one
learned from his "master" but learned "on the job."

The fact that notable cathedrals have stayed up for
hundreds of years is meaningless in the context of this
discussion. The net effect is that they have stood
the test of time. It does not mean that their
current construction was the original stonemason's
design. He may have gotten lucky, he may have
built a portion only to see it fail, but the fact
remains that the cathedral builders would build
a 10-20 meter wide section all the way to the top,
wait for the winter winds, and inspect it in the
spring to see where cracks were.

>
> You are confusing ancient stonemasons with modern programmers and all
> this example manages to illustrate is the misuse of the Middle Ages as
> well as the way in which contemporary science-worshipers (ignorant for
> the most part of science and far too familiar with science fiction)
> manage merely to lose the insight of the artisan, which the
> stonemasons had, without in fact replacing it by anything other than
> folk-lore.

I fail to parse the above paragraph.

What was replaced in the past 800 years or so, was the
"rules of thumb" of the master stonemasons, with
an application of Newton's Laws of Statics, Kinematics and
Dynamics.

Thus, we can now compute that a 100 Kmph wind at a certain
angle to a 50 meter high wall will cause the structure to
udergo certain tensile stresses at *this* point and certain
compressive stress at *that* point. (For all
points for which we care to compute.) We can now
adjust the design of the structure to compensate
for stresses which we know the materials at hand
can not stand. This is one definition of engineering.

>
>
>>We have progressed from that point in the design
>>of buildings to where we do not need to wait for
>>winter and see what falls down but to the point
>>where we can most often predict what the failure modes
>>may be and design to avoid them by the use
>>of both theoretical and empical formulae. There have
>>been, and always will be, spectacular failures.
>>Either because of poor judegment or because of
>>incomplete application of physical and matehmatical
>>principles. They are "spectacular," in part,
>>because they are relatively rare. (Your own
>>claim that 80% of IT projects fail indicates
>>that it is *not* rare in the IT industry. I will
>>not dispute that claim.)

Let me rephrase that above. I will not dispute
that at this time.

>>
>
> The fact is that the IT industry is the least unionized and in it
> there is for this reason less of a boundary between employee and
> manager. When employees are persuaded that unlike the stonemasons of
> the Middle Ages (about whom you are underinformed) they have no
> expertise worth protecting, when employees are persuaded to abandon
> this expertise and "think like a manager and not an engineer" it is
> then that the accidents happen.

Mr. Nilges. I very carefully made no personal remarks
in my original post. The "about whom you are
underinformed" above is a personal remark and a value judgement
on your part regarding my level of knowledge.
A value judgement which can not be objectively substantiated
by you, thus merely a conjecture. Based on your
previous postings, my conjecture is that you *may* have
studied the social and political implications of the
guild system, but *I* have studied the methods
of construction during the middle ages (and other
periods). I hardly think that I am underinformed
about the methods of construction.

>
>
>
>>Compare the above to the way in which much software
>>is written today. Is it more like modern day
>>engineeing which anticipates overload conditions
>>and takes steps to ameloriate or avoid them,
>>or is it more like what the state of the
>>art in building trades was 600-800 years ago?
>>
>
> It is as I have said far worse. Furthermore you cannot assume that it
> will improve with the passage of time. The 80% failure rate is
> constant and in fact, earlier systems (such as the 1972 New York Times
> information bank) were of higher technical quality, because they were
> developed under regimes that can no longer obtain.

Obtain what?

>
>
>>In my experience, the typical attitude of the typical
>>project is "we'll build it and see how fast it is,"
>>or, more to the point, "we'll build it and
>>see when it breaks."
>>
>
> Actually, it isn't. Instead, project members go through the motions of
> making obeisance to "methodologies" that are in fact sold as avoiding
> problems but cause problems on their own.

Agreed.

>
> Furthermore, the experience of Extreme development is that "we'll
> build it and see how fast it is" and "we'll build it and see when it
> breaks" is an improvement and more "productive" than the oh-so-very
> "structured" and "controlled" disasters that form most of the failed
> systems.

There are other pactices which can be applied
which try to predict whan a system will break.
Most often these involve simple arithmetic (with
a small smattering of queueing theory).

Would you believe they actually improve productivity?

>
> In fact, if you correctly apply the successive, genuine discoveries of
> the past including structured programming in detail, and OOD in the
> large, you can "build it and see how fast it is". You can "build it
> and see when it breaks".

In my opinion the practices of both Structure Programming and OOD
are very valuable, but they mostly address the issues involved
in software extensibility and maintenance. Either an SP approach
or an OOD approach may lead the apprentice programmer to choose
a bubble sort algoritm for a 100,000 entry table.

>
> Building it, and seeing how fast it is: building it, and seeing when
> it breaks, happens to be the applied scientific method and may be
> compared favorably to "we'll build it, keep our mouths shut about its
> deficiencies lest we offend powerful players, and update our resumes
> when it breaks".

Yes, it compares favorably to what you mention. Unfortunately,
it is often the grunt progammers who get the blame. What is
better, by far, is to apply whatever arithmetic we can to
the problem and see if it's doable in the first place or
whether or not it's an overconstrained problem.

For example, let us assume a problem where we must
do 1,000 transactions per second on a predefined
set of hardware. Even as a journeyman, I should
know that this is impossible given a single physical
disk drive. Before even starting the code, I should
go to the "master stonemason" and ask him what the heck
he's smoking. I should not even start to think about my
OOD or structured design before I get an answer.
Simple arithmetic.

>
> The attitude of the FBI's Virtual Case File was probably "we shall
> link together best of breed in a highly controlled fashion, defining
> 'best of breed' to mean 'software from companies that are tight with
> *** Cheney's fat pals', ignore the weakness of the links,
> systematically confuse the bestness of the breed with the weakness of
> those links, and update our resumes when the *** hits the fan".
>
>
>>I grant you, the analogy is imperfect, but,
>>given that, please tell me why you believe that
>>CS (as generally practised today) is "more than engineering?"
>>
>
> I don't believe that CS (as generally practised today) is "more than
> engineering". I believe that CS (practised properly, eg., almost
> never) is "more than engineering". I believe that CS (as generally
> practised today) is a regression to mud huts, and I believe it is an
> INSULT to mediaeval stonemasons to compare their work to modern
> praxis.

Well, I wouldn't have worded it that strongly :)

The problem may well be in that managementcritters feel
that just because you know a language you can "design."
Apprentices have to lay bricks and mix the mortar (coding?).
Journeyman can layout the shape of a small building
and supervise the apprentices (sub-system design?).
Masters can plan for grandiose buildings and supervise
the journeymen as the journeymen do what they do.
(System Design? General Contractor? other analogy)

Hmmm... I seem to be a proponent of the "guild
system". I guess everything old is new again :)

Until there is an Ohm's Law for Software (or a set
of Netwon's Laws for software), I think we will
always be in thie dilemma.

NPL 

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch
Quantcast