|
Posted by Jerry Boyle on August 14, 2006, 11:34 am
Please log in for more thread options
>
>>
>>>
>>> Hey, I was a programmer for 35 years before I recently retired.
>>> Although
>>> I sympathize with the fear of fixing a minor bug which might cause some
>>> other unrelated failure, it's always been my philosophy to fix these
>>> minor
>>> bugs whenever I came across them. It has a real positive impact on the
>>> user base to see little annoying bugs drop by the wayside. They guy
>>> making the fix needs to be more than an idiot when he makes the change
>>> to
>>> prevent additional errors. Then, of course, regression testing should
>>> be
>>> performed on each release. Competent programmers finding great
>>> difficulty
>>> fixing simple bugs without causing unlrelated problems is a reflection
>>> of
>>> a sick code base and or bad design. I certainly hope this is not the
>>> case
>>> with Quicken, although some times I wonder.
>>>
>>>
>>
>> Any fix, no matter how simple or how carefully made, runs the risk of
>> exposing an uninitialized variable or a program bug that stores a value
>> in
>> the wrong location, e. g. because of an uninitialized or incorrect
>> address
>> pointer. The fact that Quicken is a huge legacy system makes the presence
>> of
>> many such latent bugs almost 100% certain. Sick code base? Bad design?
>> Those
>> are harsh words but they're true for almost any big system that's been
>> around as long as Quicken.
>>
>> Quicken is the steward of many years of financial data for an enormous
>> number of users. That makes the possible consequences of even the
>> simplest
>> fix enormous. And I don't know what systems you worked on, but on my
>> systems
>> it was very expenssive to run full regression testing. Plus they'd have
>> to
>> retest on every platform that Quicken runs on. Even then you can't repeat
>> beta testing and prior user experience.
>>
>> If they screw up my financial data to fix your dark blue line I'm coming
>> after both you and them with a hatchet :-) I'll probably be able to find
>> the
>> programmer who did it and manager who authorized it standing in an
>> unemployment line.
>>
>
> Hey, I hear you. I've been there lots of times.
>
> I've been using Quicken since the late 80's and I'm in no hurry to screw
> things up.
>
> However, fear shouldn't be an excuse for doing a shoddy job turning out a
> product.
>
> Bet I'll bet you a 6-pack of your favorite brew that chnging the color of
> a highlighted line in a transaction report isn't rocket science and can be
> accomplished, by a competent programmer who knows what he is doing, with
> minimal impact to the honorable Quicken program. The key here is a
> "competent programmer". There are lots of idiots in the world calling
> themselves programmers. Even if the guy isn't an idiot, he has to have a
> clear apprecation of how the program works to mess around changing things.
> I always figgured that my code should be perfect and perfection was my
> goal. My code and designs were pretty good in their day. Lots of my peers
> argued that perfection isn't atainable and therefore should not be sought
> after. If I guy doesn't shoot for perfection he must be shooting for crap
> and that is exactly what he'll get.
>
> Just MHO!
>
> :-)
>
As one old retired perfectionist to another I must confess that I snuck
fixes like this in all the time, even though I was fixing others' code in
huge, complicated legacy systems. We agree that all easy-to-fix problems, no
matter how minor, should be fixed. But I still claim that these fixes belong
in the next version or major release, in this case Q2008. If I see
light-blue highlighting in Q2007 I'm comin afta ya John :-)
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML Sitemap