> P.S.  If old stories aren't apropriate for this group, let me know, and I'll stop posting them.  I hope they're enjoyable rather than annoying.

Occasionally instructive. Always worth a read.

They're fine by me.

"Bill Cox" <bill@viasic.com> wrote in message news:3EAD05C1.3090300@viasic.com...
> P.S.  If old stories aren't apropriate for this group, let me know, and I'll stop posting them.  I hope they're enjoyable rather than annoying.

Oh, I think they're a great read. Please keep posting!

P.S. I've done my best to avoid the management track.

"Bill Cox" <bill@viasic.com> wrote in message news:3EACFD6C.8000400@viasic.com...
> Yep.  As I'm sure you remember, it's nice to be in EDA in these cases.
> With a thousand or so test cases from customers, you can check for every
> obscure bug that you've had to fix in the past, and verify performance.
>   I imagine that writing compilers is possibly like that.

Very much so. My test suite is mainly a distillation of 20 years of bug reports <g>.

> I try not to let new code replace the old code until the new code does a better job, and passes all the tests.  I find most programmers ignore the old code until this stage, and then poor over it carefully looking for nuggets of wisdom.  It can be pretty hard beating a 4 year old tool without reading it to see what it does.

Frequently, those nuggets consist of "if running under operating system XX.YY, work around this weird OS bug by doing this kludge". Developing under the latest OS means the new programmers will not see the problem until it's too late.


> Of course, if a programmer's not a team player, there's not much you can
> do.  We just lost the programmer I described as the super-smart guy that
> I was having some trouble working with.  Replacing fast code with slow
> code was something he did all the time.  It was his method of debugging.
>   If he traced a problem into your code, rather than fixing it, he'd
> rewrite it in the simplest way possible, which usually was very slow.  A
> number of times, the tool just slowed down to a crawl, and I spent a day
> tracing the problem to one of his fixes.  Also, the tool got somewhat
> slower every day.  I've had to abondon the entire code base he was
> involved with even though I wrote half of it, and I'm working lots of
> overtime rewriting it now.

He doesn't sound that smart to me <g>.