Return to index: [Subject] [Thread] [Date] [Author]

Workload squeeze: why.

[Subject Prev][Subject Next][Thread Prev][Thread Next]
[This message combines points made in recent threads on the ENR Article, and
on Application Service Providers.]

Dennis, Happy 50th-- when you can get to it.

In recent postings on the ENR thread, you have hit squarely on the problem:
we engineers are increasingly being squeezed between the rest of the world's
expectations (many of which do not reconcile) and our own profession's
self-important ideals, which have persisted in writing codes that in
practice prevent efficient, expeditious performance of our work. 

Steel specialist Peter Higgins has drawn a most important distinction, in
his comparison between LRFD and other steel design codes he knows of: many
can give satisfactorily valid results, and some are convenient and efficient
to use, but the one taking over U.S. code is (as he finds it) a laborious
and circuitous nuisance to use, for no compensating gain in the end result. 

Does his finding in steel codes not also apply in all likelihood to SE-
originated seismic code?  Who can state with confidence that these recently
recast seismic codes, which slow our work and at the same time leave us more
open to accusations of mis-following them, have been developed with any real
priority for efficient, convenient, and unambiguous use by the intended
user? Who can say that they are even halfway optimized for safe and
effective use by every level of licensed engineer user?  

On that recent ASP thread, many expressed their belief that competition
among commercial software applications developers will improve the breed,
and that those applications which favor the user's interests will gain the
user's favor. I suppose so, but what about the vexing, unavoidable
"application" that building code constitutes? Codewriting is increasingly a
one-source monopoly, and increasingly is a government controlled and imposed
one at that. Ordinary code users like us have been shut out as a matter of
policy and practice, even by the professional associations that live on our
(I know this personally from being on one of the SEAOC chapter code
committees, whose work has been made meaningless in recent years.)

I have been telling frustrated colleagues and clients that since "the
public" and its benefactors took over code development, and made a fetish of
code complexification in the name of protecting the public, that same public
had better get used to being "protected" from economical and expeditious
performance of engineering work.

One of these days that public is going to realize that the engineering
profession's leader/controller class has featherbedded its own high-end
role, but not that of the small-job engineers. As you have lamented, and as
Bill Allen and others have in past months, fees and office resources can't
even keep pace with the code-imposed busywork and tail-chasing being imposed
on us by agents of our own profession. There's no payoff, either in money or
ego gratification, to most of us. 

And what about payoff to the building structures? Granting that true code
"improvement" is a good thing, not just ANY code change purporting to be
better for buildings is necessarily a good balance of benefit against
detriment. If the Peter Higgins Principle has merit, different code changes
or refinements than the ones adopted by the code monopoly might have served
more purposes better serving the broadly beneficial purpose of
getting a good job done easily.

Yesterday I read a syndicated columnist who said of policymaking in another
field, "Conservatism is supposed to be skeptical of grandiose or reckless
schemes which throw out the good in pursuit of the perfect." I wish there
were some codewriters interested in being conservative in that sense. 

Meanwhile, Dennis, enjoy your entry into the ranks of we credible seniors.

Charles O. Greenlaw SE   Sacramento CA.