[thelist] Re: thelist digest, Vol 1 #2318 - 45 msgs

[.jeff]

carol,

first you say...

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I've never worked for them [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and then you go on to say...

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Suppose you're supposed to be a macho coding team, and
> you're assigned part of a project, and the part(s)
> you're depending on to TEST your part isn't (aren't)
> ready yet. What do you do? Of course! You do a quick
> and dirty (very dirty) parse of the other team's code,
> so you can test yours. Just for context, right? And
> what happens then? Well, you're in a very macho
> environment (nerdy-macho, as in "I worked 14 hours
> yesterday. I only slept 9 hours last week!"), so of
> course things fly by, there's little control over
> version changes and other non-macho stuff (like,
> quality control, or beta testing, or listening to the
> customer)... So the bits of code get squashed together
> to meet the deadline. [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

this sort of assumptive deduction has no merit.  if you'd ever worked for
microsoft, you'd know the rhetoric above simply isn't how it works.  how do
i know?  well, i work with someone that's worked on several high-profile
microsoft products through several stages of development -- ren which
eventually became outlook, the original publisher, pieces of exchange.  more
importantly, he worked in the quality control department -- the very thing
about microsoft you imply you know so much about.

not only are the steps a product had to go through to make it to market very
rigorous, but the demands made upon developers by the quality control
department make most software development cycles seem like child's play.
many software development companies could only dream of having their shit
together half as much.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> You know this because you see the result: [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

you assume it to be true, but you don't know it by the result.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> NO consistency in the interface, [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

no consistency?  hardly a factual statement.  take a read on the
requirements for a software vendor to receive an official "made for windows"
badge on their software product.  you'll find the their *very* strict.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> and multiple (conflicting!) ways of turning things on
> and off; [...]
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

which came first, multiple ways of turning things on off or the adage that
with computers you can always achieve the same task in different ways?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> the dead giveaway is: documentation almost never matches
> the product.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

this is an unfortunate occurrence (though not to the extreme you suggest),
but not a dead giveaway of what you might think.  documentation doesn't
exactly match the product because it's developed at the same time the
product is being developed from the same spec document.  that's why it's so
important for qc to be rigid with their testing so the product matches the
original spec as closely as possible and hence the documentation for the
product matches as closely as possible.  it has to be done this way.  if it
weren't and the documentation were developed after the product was developed
then the time to market for the product would be abysmally slow.

please, don't assume.  don't tell others what you assume.  don't pass your
assumptions on as fact unless you really know they are true.

<tip type="ColdFusion" author=".jeff">

don't mess with the "check that file exists" checkbox for the .cfm file
extension on the iis site if you're using any cfgraph functionality.  if you
do you'll get nothing but broken images or flash movies where graphs should
be.  that's because cfgraph makes a call to /CFGraphingPage.cfm passing
parameters to drive the type and style of graph that's displayed.

don't bother searching for a CFGraphingPage.cfm template on your server.  it
simply doesn't exist.  i suspect that the coldfusion server simply looks for
this request and executes a built-in jrun process to answer it.  however, if
iis checks to see if a file exists before handing it to coldfusion, then it
will obviously fail (since it doesn't exist in the requested path or at all,
for that matter) and never get passed on to coldfusion.

</tip>

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/