DTDs vs TMTOWTDI Was: Re: SPUG: SGML the past language of..

Fred Morris m3047 at inwa.net
Sat Dec 14 11:37:41 CST 2002


DTDs are the antithesis of TMTOWTDI. That is a question which can be
examined in the context of "Perl culture".

In responding to Michael I got a little off-track. Matching quantity for
quantity, I thought I'd take another crack at what I think is really the
core issue. I suppose now I need to either apologize for posting this
essay, or for making that cryptic remark in the first place. :-\


There's interesting stuff going on in practically every field of science,
and there's plenty of stuff that's gone on that's plenty interesting as
well. But biotech isn't special in this regard. If there's something
interesting going on, if somebody goes to some meeting and they learn
something interesting and they want to post a field report, I think that's
great.

I've worked for Immunex, Targeted Genetics, Corixa and NeoRx. As a field
engineer for a document management systems vendor I visited, among other
places, Amgen, Genentech and Isis Pharmaceuticals. I've had some even more
unremarkable assignments, jobs and job interviews in other industries over
the years. I've learned all kinds of things that were interesting and that
have little or nothing to do with software engineering, oftentimes the most
interesting stuff is anecdotal and has little to do with the problem at
hand.


When I say "..biotech isn't special.." I mean sic in vitro sic in vivo (or
perhaps in this case the other way around). I've seen well-run operations
and some which are not so well-run.

There are some interesting problems to solve. A lot of math and
interpolation. "Random" three-letter sequences which are anything but (an
interesting challenge in requirements specification). Whiz-bangy software
for figuring out which primers to use, and how not to get dimers; graphical
tools for molecular modeling and visualization. Large patent and genetic
sequence databases.

The hot room, where all of the counters are: Do you put gloves on when you
go in to use a keyboard, or do you take them off? Everything in the room is
presumed "hot". That means that if you put on gloves, they need to be
treated as "hot"; therefore, they go into the radioactive waste stream.
It's all risk management. The levels of radioactivity are extremely low in
any case, you're dealing with live critters and too much ionizing radiation
is going to introduce an unacceptable amount of noise into the metabolic
equation. Plus they swab the room, and for that matter the building, every
so often. You're the bean counter, you decide: do people put on gloves, or
do they take them off? You have to go into the hot room: do you trust your
colleagues to follow the rules or not?

Memo tacked to the bulletin board somewhere: "..remind you to remove gloves
when greeting visitors..". I generally stood aside and let someone who
worked in any particular lab open the door.

Michael Crichton has a medical degree. Sulphur: it doesn't stay where you
put it. Many labs (most of these entities have more than one lab) are run
in charismatic as opposed to bureaucratic fashion. As someone once remarked
talking about why some of his colleagues could get recombinant yeast to
grow, and others couldn't: "just because you have a PhD in Biology doesn't
mean you can bake bread."

You may find yourself implementing that sophisticated algorithm using
Excel. A lot of these people sit down at a computer and it's pure voodoo;
just because you've got a PhD doesn't mean you understand a computer virus.
It doesn't work in the lab, but somehow if they try something on a computer
and it doesn't work they figure if they try it again exactly the same way
they'll get a different result.


It's just like any other industry: some people are engineers, and some of
them are gene jockeys. They just have some toys to play with which maybe
make it all a little more serious if you screw up. I don't mind
environments like that. Of all of the environments which I've worked in,
those which had cool toys and where the personnel were diligent and adhered
to some appropriate engineering standards have been my favorites. In such
cases, bureaucracy has generally been a good thing.

I'm generally in favor of bureaucracy ascending over charisma when life or
safety is an issue... or even when it simply costs $10000/hour when the
line is down or the boat doesn't leave. In fact an engineering orientation
is for me the determining factor in where I want to work, not the
particular industry. I don't trust charisma.


In the context of this struggle between charisma and bureaucracy, DTDs are
one attempt to supplant charisma with bureaucracy. (You don't think this
sort of definitional struggle really goes on? Look at the politics of
growth factors and chalones.)

One of the reasons people who are in "hard" engineering disciplines get so
snitty about people talking about "software engineering" is, I think, that
they generally don't see a whole lot of engineering going on. This isn't
just the practitioners, it can be the expectations of the people whose
problems we're trying to solve: their approach to the lab may be
professional, but their approach to their information processing tools can
be amateurish and consequently they don't expect us to behave as engineers
in our professional domain. Be that as it may, "There's More Than One Way
To Do It" isn't going to test well when some jury is trying to apportion
liability.


There is a "Perl culture" question in all of this:

DTDs are an effort to define exactly one way to do something. How do you
rationalize "There's More Than One Way To Do It" with a concerted effort to
define exactly one way to do something? Are they using Perl because
"There's More Than One Way To Do It", or for the same reason that I do,
that it's relatively stable and well-supported and I can make it behave in
a predictable and well-defined fashion? Are they really interested in XML
because it's "new"?


I wrote:
>>[...]
>How it is, is that XML is an offshoot of SGML.
>
>SGML has been utilized for some time now in mechanical systems design and
>documentation. Additionally, there are large government-sponsored research
>and development activities, and in some cases deployments, which have gone
>on in parallel but overlapped; working groups have gotten together to
>define basically XML, the common metadata, to describe and integrate these
>domains of knowledge.
>
>It's a management issue.
>[...]
>One of the more intriguing aspects of records management is retention
>guidelines
>[...]
>I didn't see "bureaucracy" as inherently a "down side".
>[...]
>Granted, there are a lot of interesting characters in the Perl culture. ;-)
>But is it really because of Perl, or because of Ingy's leather pants?
>
>If the bureaucracy uses Perl, then is it a Perl culture?
>[...]
>XML may not be "better", it may
>just be what the bureaucracy already understands.

--

Fred Morris
m3047 at inwa.net



 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org




More information about the spug-list mailing list