From: Pete Dashwood on
Howard Brazee wrote:
> On Thu, 25 Feb 2010 12:55:55 -0700, "James J. Gavan"
> <jgavandeletethis(a)shaw.ca> wrote:
>
<snipped stuff about lager. Maybe note in passing that "lager" in German
means "warehouse or storehouse". They call it Pils after the town of Pilzen,
now in the Czech Republic, but prior to the last big worldwide squabble,
part of Germany. I spent a hazy Summer day there with a Czech girl from
Prague; the beer, the place and the people were delightful. :-)>

>
>
> So - I wonder how much of programming arguing is actually backed up
> with productivity figures and how much is taste.

I have come to the conclusion there is no point in arguing about it. (this
represents a major growth achievement for me. It only took about 20 years of
posting to CLC... :-))

For me, all that matters is that stuff should work and it should be got
working smartly. I don't think that computer programming as we understood it
30 years ago is where the future lies anyway.

Today's programmer simply cannot be a "one trick pony". It is about breadth
of knowledge, tools, skill, and most importantly, understanding of business
needs and processes (if you intend to work in commercial environments.). I
spent 4 hours today trying to find out why SQL Server hung when it was faced
with SELECTing multiple rows of data into an array of host variables using
ESQL. Sometimes it worked; sometimes it didn't... (Those are always the most
interesting problems... :-)) In the course of running down the solution I
found out a lot more about SQL Server than I really wanted to know, but that
is the nature of problem solution these days. It's no good leaving it to the
DBA because: (a). I don't have one, (b). If I hired one it would take a day
or two, and I don't have a day or two, and (c), if my code is causing this
problem I want to know about it.

I was immensely relieved to find out that my code WAS causing it, but in a
very easily fixable way...

Hint:

If you are writing ESQL and dealing with SQL Server (and I can only imagine
people doing this because they HAVE to... it certainly wouldn't be my
choice), don't write code like this when you do PUT operations...

if SQLSTATE = '00000'
EXEC SQL
commit work
END-EXEC
end-if

On the face of it, it seems quite sensible. Why would you want to commit a
transaction that failed?

Because of something called LCK_M_S... And sometimes when something
appears to have hung, it actually hasn't. It is just suspended.

(Full details by private mail for people who are experiencing SQL Server
hangs when using Embedded SQL...:-))

The point is that thirty years ago, I would have called a DBA and said: "I'm
a programmer, not a Database guy, can you tell me why it is doing this?"
Today's programmer has to be more...



>
> It could be hard to find. I've seen a change in expectations of
> users over the years from designing a system around the business needs
> towards adjusting business to fit the system.

I think there has always been a tendency to do that, Howard, and it has been
actively encouraged by IT people... :-)

As systems have become less bespoke, more packaged, and in many ways, more
powerful, a good business case can often be made for changing certain
processes to fit the package being installed. Like everything else, each
case has to be judged on its merits.

Pete.
--
"I used to write COBOL...now I can do anything."


From: Howard Brazee on
On Sat, 27 Feb 2010 00:37:27 +1300, "Pete Dashwood"
<dashwood(a)removethis.enternet.co.nz> wrote:

><snipped stuff about lager. Maybe note in passing that "lager" in German
>means "warehouse or storehouse". They call it Pils after the town of Pilzen,
>now in the Czech Republic, but prior to the last big worldwide squabble,
>part of Germany. I spent a hazy Summer day there with a Czech girl from
>Prague; the beer, the place and the people were delightful. :-)>

If I say I don't care for pilsners, few people around here know what
I'm talking about. I wasn't familiar with the German "Pils".


>> It could be hard to find. I've seen a change in expectations of
>> users over the years from designing a system around the business needs
>> towards adjusting business to fit the system.
>
>I think there has always been a tendency to do that, Howard, and it has been
>actively encouraged by IT people... :-)
>
>As systems have become less bespoke, more packaged, and in many ways, more
>powerful, a good business case can often be made for changing certain
>processes to fit the package being installed. Like everything else, each
>case has to be judged on its merits.

As a programmer, my first instinct was that this is a bad trend. But
I've changed my mind. Sure there are some instances where an
off-the-shelf tool doesn't really give competitive advantage. But I
work for a university - our competitive advantage isn't in having a
unique billing system.

Just as a carpenter doesn't have a competitive advantage in making his
own hammers.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison