|
PureBytes Links
Trading Reference Links
|
Ernie,
Thank you for taking the trouble to reply.
You have certainly described the way things are. Is it good or bad? I
leave that to God and the Market.
If you have a useful product and there is nothing better, many will buy it -
and start to complain as they begin to find bugs. At first they will call
up, try to get support. Very quickly you will hire special people just to
field these calls. Not long after that, you will find that paying a staff
large enough to handle all the calls is a significant part of your budget -
so you will start charging for Tech Support. This will turn many people
off, send them raving to bulletin boards. Others, used to this system (say,
Omega, Symantec or Microsoft customers), will develop their own fixes,
work-arounds or simply learn to live with the limitations. Of this last
category, some will make a career of the software, gradually establishing
themselves as experts, others will use the software as long as they have to,
while looking for a replacement.
Is this The American Way? Well, its certainly the way of a lot of
Americans - and others as well. And it promotes competition.
Could it be done any other way? Decidedly yes: the oldest adage in
programming is "do it right or do it again". More time in design and
testing - and documenting, that Black Hole of software production - would
mean fewer people on the telephone. But how many products are conceived -
or at least designed - by experienced software engineers? Where, for that
matter, do you even find any such people? Programmers are cannon fodder -
most don't last long, at least in the same job and seldom indeed does
management have the purse and the patience for long development.
So, as you say, you learn to accept it. And the people who use it do kinda
like it - figuring that it would be difficult to replace. And thinking of
all their learning investment in it. The good is the enemy of the
excellent - but what're you gonna do? Somewhere, somebody is thinking,
scribbling! I digress...
Jim
-----Original Message-----
From: Ernie Bonugli [mailto:ebonugli@xxxxxxxx]
Sent: Monday, 17 December, 2001 10:41
To: omega-list@xxxxxxxxxx
Cc: Jim Wixson
Subject: Re[2]: variable declarations within EL?
Hello Jim,
Knowing what we know about managing complex large software development
projects, you accept the bad for the sake of the the good.
On my last commercial project, we developed and sold thousands of copies of
a program. Throughout my involvement we maintained a constant large # of
Software Trouble Reports. No matter how hard, and late into the night we
worked, we were never able to put a dent on the number of problems. The
program is still a success and is being used thruout the states. It is
difficult to justify $wise, a staff to just fix problems. You can justify
adding features and in doing so, you can take care of the bugs. Thereby you
get the never ending story. Programming staffs concentrate on the severe
problems, those abnormally terminate the app, or corrupt the data base. It
quickly becomes apparent that you will never be able to fix those countless
little bugs. Unless the programmer stumbles into the problem, recognizes it
a problem, and is able to replicate it, the problem will not get fixed.
That programmer is probably not assigned to the problem in the first place.
He is working on something more important, a new feature. By the way, that
same programmer is adding his own brand new bugs to the software with every
line of code he alters or adds!!
So with this experience, you learn to accept TS. I kinda like it. I think
it will be difficult to replace it with something that is better and as as
stable. We forget that TS has solved 1,000,000,000s of problems since it
first release.
Ernie mailto:ebonugli@xxxxxxxx
|