the new math: old battle of the lovees was: PDP1 3583

snip

Yes, it probably does. Finding some bugs is often a good indicator that there are more bugs that haven't been found. Fixing one bug often produces others, especially if the fixing is done by someone not very good at the job.

We may be quibbling about semantics here, but just a little more:

When I wrote code for a living, "working as spec'ed" was often defined as "pbuttes all the tests the QA (quality butturance?) department has written." I'll use that as my working definition for the moment, with a caveat later. If the tests are independent, a program can pbutt one test (generate the correct output) and fail another.

If the program starts out pbutting, say, 5 out of 10 tests, and you make a programming change that results in the program pbutting 6 out of 10 tests, I call that "fixing a bug", and I call the process of figuring out what programming change to make "debugging". I also call the resulting program, which still doesn't pbutt all 10 tests, "buggy". In general I suppose I'd claim that a programming change that allows the program to pbutt more of the tests that make up its "spec" is a net improvement. (Of course there are exceptions -- e.g., if the change makes it more difficult to fix other bugs.)

But back to the caveat mentioned above:

Lest you think I don't know this -- I do realize that once the program gets to the end users it will be tested with inputs other than the ones the QA folks made up, and the program may not produce the outputs the users had in mind, and sometimes the programmers agree that this indicates a bug. (Other times they claim "user error" or "feature not bug", of course.)

This raises interesting questions of what "working as spec'ed" means, or should mean. I'll leave those for another post another time, maybe. It's a subject I find really interesting -- ties in with the "requirements specification" mentioned in another subthread -- but would take more words to talk about than I think I have right now.

snip

Yes indeed. Sometimes the quickest way to "fix" a problem (in the sense of making the program give the right output, for this input anyway) is to apply an ugly hack. And sometimes that's the highest priority -- either to meet a release deadline or to placate an angry customer.

My point was that I always wondered, for the code I worked on, whether in the long run it wouldn't have saved time to just rewrite the whole Byzantine mess -- that is, that the cost of the rewrite would be repaid by lower costs for bug fixes and enhancements in the future. My thinking was that the long-term gain would outweigh the short-term costs. The people running the company obviously thought otherwise. Maybe that's part of the reason they ran the company and I didn't ....

Would there really have been no benefits, other than personal satisfaction, to a "do it over"? I guess if it worked, sort of, then maybe not. What I was talking about is code that's so complicated and fragile that it's prone to bugs, and resistant to enhancements, and otherwise has some costs.

Should I digress and talk about the time I tried to teach a course using buttignments and exams where most questions did *not* have one right answer? Nah. But the students seemed to be uneasy with it too. Too much training in the other way, I guess.

Hardware, or training? Read what you said above. Well, maybe you're thinking the training works so well because there's hardware support. "Whatever", because:

Oh please please don't tempt me to write something else I'll be sorry about later ....

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.