Re: what would be a good substitution for wind in a laborato

mmeron_at_cars3.uchicago.edu
Date: 12/10/04


Date: Fri, 10 Dec 2004 21:00:24 GMT

In article <4_2dnbYKFeT-CiTcRVn-2g@rcn.net>, jmfbahciv@aol.com writes:
>In article <gd4ud.29$45.11547@news.uchicago.edu>,
> mmeron@cars3.uchicago.edu wrote:
>>In article <KuKdnc4vF4VxryXcRVn-hw@rcn.net>, jmfbahciv@aol.com writes:
>>>In article <ImLtd.20$45.9115@news.uchicago.edu>,
>>> mmeron@cars3.uchicago.edu wrote:
>>>>In article <nrCdnVj97_JCnCrcRVn-sg@rcn.net>, jmfbahciv@aol.com writes:
>>>>>In article <eiqtd.14$45.5931@news.uchicago.edu>,
>>>>> mmeron@cars3.uchicago.edu wrote:
>>>>>>In article <41b600bc.431051744@news.ucalgary.ca>,
>kmuldrezw@ucalgazry.ca
>>>>>(Ken Muldrew) writes:
>>>>>>>glhansen@steel.ucs.indiana.edu (Gregory L. Hansen) wrote:
>>>>>>>
>>>>>>>>I forget who said it, but some physicist said that the ideal
>>>experiment
>>>>>>>>will hold together long enough to take all the data that's needed,
>but
>>>>>no
>>>>>>>>longer. Otherwise you'd have wasted time and money over-engineering
>>>it.
>>>>>>>
>>>>>>>The principle still lives on. Just take a look at the computer
>>>>>>>programs that researchers write (woe unto you if you're given the
>task
>>>>>>>of reviving a bit of code that's not in current use).
>>>>>>>
>>>>>>:-))) Many years ago, while being temporarily "between jobs", I was
>>>>>>offered a short term contract to upgrade a program having to do with
>>>>>>nuclear medicine. The program was written circa 1960, in Fortran (the
>>>>>>original one, not even Fortran 4) and none of the people having
>>>>>>anything to do with it was still around. The contract was offered for
>>>>>>3 months. After looking the program over I told them that I can give
>>>>>>them a brand new program, written from scratch, in 3 months, but if
>>>>>>they insist on upgrading the original, it'll take at least 6 months.
>>>>>
>>>>>I bet the manager peed in his pants.
>>>>
>>>>Pretty much so.
>>>>
>>>>> Managers absolutely hate this
>>>>>because there are just too many unknowns. Now that I'm thinking
>>>>>about it, fellow programmers hate it, too, because there are too
>>>>>many unknowns.
>>>>
>>>>Meaning, "too many obvious unknowns". The other approach has as many
>>>>or more unknons, only they're not as obvious.
>>>
>>>True. The other approach is known to have worked once upon a
>>>time. One of the risks of a rewrite is that all those bandaids
>>>come off all at once, and you can suddenly find yourself up to
>>>your bellybutton in alligators even if the spec stated that you
>>>were in the desert.
>>
>>For sure. However, as things stood, the original program consisted
>>mostly of band aids and there was no way to avoid touching those even
>>within the framework of a "minimal rewrite". So, it appeared safer to
>>toss the whole mess overboard and start from scratch.
>
>I had one of those once but wasn't allowed to do a rewrite since
>the author worked years on perfecting the mess.

Well, of course. A great mess isn't created all at once, it needs
time to mature, like wine.

> He had the notion
>that "saving" code was calling a paragraph from the middle of
>a USING statement (it was COBOL). Later, I simply reworked the
>software that produced the input to that COBOL program.
>When we shipped it, we were thanked by computer center PHBs who
>could reassigned their systems programming to doing real work
>rather than converting mixed mode data into ASCII for downstream
>billing programs.

I'm sure they were quite happy about it.
>
><snip>
>
>>> I can already tell how the coder wrote it.
>>
>>:-)))
>
>Yep, definintely a three-)er.
>>>
>>>Did you have the convenience of a functional spec written
>>>in English ASCII or did you need to divine it out of the code?
>>>
>>No spec (functional or otherwise) available. But, I had at my
>>disposal a postdoc who used the old program for couple years and who
>>could provide the answers to two crucial questions:
>>
>>1) What was it that the program was doing for him?
>>2) What he would like the program to do for him?
>>
>>That was quite enough.
>
>That's even better, especially the second. JMF became
>a bit god over and over again because he remembered to
>ask the second.

Indeed, that's crucial. It is all to often that useless program
features are perpetuated while potentially useful ones are not being
introduced, only because people ask just the first question, not the
second.
>
>> ..And, there was a functional spec written (for
>>the new version) when I finished.
>
>You're hired. Not many people would do that last 5% of the
>project that causes the ASCII to match the executable.
>
Well, these last 5% are a pain. But, apparently I did a good job
explaining to them how their stuff cannot be well upgraded since it
has no documentation. Got them convinced and then they absolutely
insisted that the scope of the projected *must* include documention,
not just programming. Served me right:-)

Mati Meron | "When you argue with a fool,
meron@cars.uchicago.edu | chances are he is doing just the same"



Relevant Pages

  • What Killed Smalltalk?
    ... Smalltalk died of a hundred cuts. ... It didn't die ... Many add-ons like GUI developers were a mess in themselves ... documentation or a link to such documentation. ...
    (comp.lang.smalltalk)
  • Re: What happened with python? messed strings?
    ... I used extensively python and now I find this mess with strings, ... Basically you're not using ASCII encoding in your source text... ...
    (comp.lang.python)
  • Re: HELP (RPM - what package a file is from)
    ... to mess up a linux box, you need to work at it; ... to mess up an ms windows box, you just need to *look at* it. ... 'The Linux Documentation Project' http://www.tldp.org/ ... Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org ...
    (Fedora)
  • Re: Where to start
    ... Documentation is generally a mess. ... produce new documentation based on your findings. ... I am making some kernel changes here (because I need IA32 instruction set ...
    (comp.os.linux.development.system)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... reasons for Unicode is to escape the mess of incompatible extenstions ... to ASCII - for example most of Europe needs ISO-8859-15 not ISO-8859-1 ...
    (sci.crypt)