Prev: SQL Server Performance Local vs Remote.
Next: Trying to get a % of responses from a survey in a query
From: Geoff Schaller on 8 May 2010 01:32
But you're still an old fart.

Get with the times. Stop acting like a news group nazi and just answer
the folks. Then politely request more details if necessary, instead of
cut and pasting out of some by-gone era text book.



"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:16e87f04-374d-4de7-9f76-6b3a79d77825(a)n15g2000yqf.googlegroups.com:

> >> You're such an old fart. <<
>
>
> True, but at least I am not rude :)
>
>
> >> The problem was easily dealt with by more tolerant types that appeared more interested in assisting than asserting some academic dogma from the past. <<
>
>
> Actually, look at the thread. Plamen asked "Is there any relation
> between the tables?" which is the same thing I did, but I was more
> precise about it.
>
> It also says a lot that you regard clear specs as "academic dogma from
> the past"! LOL! This is like the joke about programmers who write
> code blindly then try to tell the client that it might not be up to
> spec but it works as coded.
>
>
> >> Did you notice the problem was solved quite happily without your prognostications? <<
>
>
> We don't know if this is solved yet. Marilyn hasn't posted back. From
> third posting, my thought was that we need a skeleton like:
>
> UPDATE TaxOrders
> SET s_anme
> = ( << expression with ConusSolLyr >> )
> WHERE taxor = 'Alfisols';
>
> But, we have no idea what the keys are, or even which tables the
> columns come from. Her mix of casing and improper data element names
> offer no help.
>
> Now, looking at YOUR suggestion .. oh, there wasn't any!

From: Tony Rogerson on 8 May 2010 03:22
> True, but at least I am not rude :)

Come now Joe.

You've built your reputation on being rude, arrogant and condescending.

Clear specs are great - however, out in the real world professionals usually
work without clear specs and your comments and diatribe only reinforce our
view that you've no real world industrial experience other than training
gigs which isolate you from requirements analysis altogether.

--ROGGIE--

"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:16e87f04-374d-4de7-9f76-6b3a79d77825(a)n15g2000yqf.googlegroups.com...
>>> You're such an old fart. <<
>
> True, but at least I am not rude :)
>
>>> The problem was easily dealt with by more tolerant types that appeared
>>> more interested in assisting than asserting some academic dogma from the
>>> past. <<
>
> Actually, look at the thread. Plamen asked "Is there any relation
> between the tables?" which is the same thing I did, but I was more
> precise about it.
>
> It also says a lot that you regard clear specs as "academic dogma from
> the past"! LOL! This is like the joke about programmers who write
> code blindly then try to tell the client that it might not be up to
> spec but it works as coded.
>
>>> Did you notice the problem was solved quite happily without your
>>> prognostications? <<
>
> We don't know if this is solved yet. Marilyn hasn't posted back. From
> third posting, my thought was that we need a skeleton like:
>
> UPDATE TaxOrders
> SET s_anme
> = ( << expression with ConusSolLyr >> )
> WHERE taxor = 'Alfisols';
>
> But, we have no idea what the keys are, or even which tables the
> columns come from. Her mix of casing and improper data element names
> offer no help.
>
> Now, looking at YOUR suggestion .. oh, there wasn't any!

From: Geoff Schaller on 8 May 2010 03:43
You know the funny thing is that almost every IT project costs double
what is originally quoted. I've had many clients who exclaim to me later
that they wish they had held me to my quote. To which I immediately
reply: in that case they would only have received what they asked for in
their spec.

The reality is that we don't get specs. Certainly not detailed ones. And
when I have had to complete a genuine RFT or formal quotation, I would
say that initial spec would never cover more than 30% of what is
eventually built.

We now have an attitude of continual delivery and continual billing. We
agree on small milestones which they are happy to pay on. Each milestone
statement is accompanied with some kind of forward estimate of work
remaining but we find that the customer 'customises' the work so much
along the way that putting too much effort into a detailed spec is just
pure wasteful. It is often fantasy.

Geoff Schaller
Software Objectives


"Tony Rogerson" <tonyrogerson(a)torver.net> wrote in message
news:43A5EC0E-CCD1-431D-AA9E-5F1A66B44923(a)microsoft.com:

> > True, but at least I am not rude :)
>
>
> Come now Joe.
>
> You've built your reputation on being rude, arrogant and condescending.
>
> Clear specs are great - however, out in the real world professionals usually
> work without clear specs and your comments and diatribe only reinforce our
> view that you've no real world industrial experience other than training
> gigs which isolate you from requirements analysis altogether.
>
> --ROGGIE--
>
> "--CELKO--" <jcelko212(a)earthlink.net> wrote in message
> news:16e87f04-374d-4de7-9f76-6b3a79d77825(a)n15g2000yqf.googlegroups.com...
>
> >>> You're such an old fart. <<
> >
>
> > True, but at least I am not rude :)
> >
>
> >>> The problem was easily dealt with by more tolerant types that appeared
> >>> more interested in assisting than asserting some academic dogma from the
> >>> past. <<
> >
>
> > Actually, look at the thread. Plamen asked "Is there any relation
> > between the tables?" which is the same thing I did, but I was more
> > precise about it.
> >
> > It also says a lot that you regard clear specs as "academic dogma from
> > the past"! LOL! This is like the joke about programmers who write
> > code blindly then try to tell the client that it might not be up to
> > spec but it works as coded.
> >
>
> >>> Did you notice the problem was solved quite happily without your
> >>> prognostications? <<
> >
>
> > We don't know if this is solved yet. Marilyn hasn't posted back. From
> > third posting, my thought was that we need a skeleton like:
> >
> > UPDATE TaxOrders
> > SET s_anme
> > = ( << expression with ConusSolLyr >> )
> > WHERE taxor = 'Alfisols';
> >
> > But, we have no idea what the keys are, or even which tables the
> > columns come from. Her mix of casing and improper data element names
> > offer no help.
> >
> > Now, looking at YOUR suggestion .. oh, there wasn't any!

From: TheSQLGuru on 8 May 2010 10:12
> True, but at least I am not rude :)

That is a stunningly brash and false statement!!!


--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net


"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:16e87f04-374d-4de7-9f76-6b3a79d77825(a)n15g2000yqf.googlegroups.com...
>>> You're such an old fart. <<
>
> True, but at least I am not rude :)
>
>>> The problem was easily dealt with by more tolerant types that appeared
>>> more interested in assisting than asserting some academic dogma from the
>>> past. <<
>
> Actually, look at the thread. Plamen asked "Is there any relation
> between the tables?" which is the same thing I did, but I was more
> precise about it.
>
> It also says a lot that you regard clear specs as "academic dogma from
> the past"! LOL! This is like the joke about programmers who write
> code blindly then try to tell the client that it might not be up to
> spec but it works as coded.
>
>>> Did you notice the problem was solved quite happily without your
>>> prognostications? <<
>
> We don't know if this is solved yet. Marilyn hasn't posted back. From
> third posting, my thought was that we need a skeleton like:
>
> UPDATE TaxOrders
> SET s_anme
> = ( << expression with ConusSolLyr >> )
> WHERE taxor = 'Alfisols';
>
> But, we have no idea what the keys are, or even which tables the
> columns come from. Her mix of casing and improper data element names
> offer no help.
>
> Now, looking at YOUR suggestion .. oh, there wasn't any!


From: Kalen Delaney on 8 May 2010 10:46
I assumed that Joe's smiley meant he was well aware of how rude he is, and
was trying to make light of it.

--
HTH
Kalen
----------------------------------------
Kalen Delaney
SQL Server MVP
www.SQLServerInternals.com

"TheSQLGuru" <kgboles(a)earthlink.net> wrote in message
news:tamdnUhIsJTg7XjWnZ2dnUVZ_i2dnZ2d(a)earthlink.com...
>> True, but at least I am not rude :)
>
> That is a stunningly brash and false statement!!!
>
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
>
> "--CELKO--" <jcelko212(a)earthlink.net> wrote in message
> news:16e87f04-374d-4de7-9f76-6b3a79d77825(a)n15g2000yqf.googlegroups.com...
>>>> You're such an old fart. <<
>>
>> True, but at least I am not rude :)
>>
>>>> The problem was easily dealt with by more tolerant types that appeared
>>>> more interested in assisting than asserting some academic dogma from
>>>> the past. <<
>>
>> Actually, look at the thread. Plamen asked "Is there any relation
>> between the tables?" which is the same thing I did, but I was more
>> precise about it.
>>
>> It also says a lot that you regard clear specs as "academic dogma from
>> the past"! LOL! This is like the joke about programmers who write
>> code blindly then try to tell the client that it might not be up to
>> spec but it works as coded.
>>
>>>> Did you notice the problem was solved quite happily without your
>>>> prognostications? <<
>>
>> We don't know if this is solved yet. Marilyn hasn't posted back. From
>> third posting, my thought was that we need a skeleton like:
>>
>> UPDATE TaxOrders
>> SET s_anme
>> = ( << expression with ConusSolLyr >> )
>> WHERE taxor = 'Alfisols';
>>
>> But, we have no idea what the keys are, or even which tables the
>> columns come from. Her mix of casing and improper data element names
>> offer no help.
>>
>> Now, looking at YOUR suggestion .. oh, there wasn't any!
>
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SQL Server Performance Local vs Remote.
Next: Trying to get a % of responses from a survey in a query