From: Dave M. <mc...@ne...> - 2008-09-06 05:20:51
|
On Sep 6, 2008, at 12:53 AM, Richard Erlacher wrote: >>> One can only file a bug report if one finds what's known to be a >>> bug. If >>> you don't know what the code is intended to do, you can't possibly >>> know >>> whether what you've observed is outside that scope. >> >> If it generates bad output, or drops core... >> > How would you know that? Well, if the latter, it's obvious. If the former...I'd step through the generated assembly code and see if it makes sense. I've found quite a few compiler bugs that way. None in SDCC, though, which I think is worth mentioning. > I don't know about the suits, but procedure-oriented people turn > out the > satisfactory product within schedule and budget almost all the time. I don't agree, and further, I don't know of anyone, in any field, who would agree. In support of my position I'll offer up the fact that, tonight, I've written C code for an 8051, compiled it with SDCC, and run it...while you're still complaining that the SDCC maintainers don't push enough paper around to satisfy your personal need for procedures. > If > that's not goal-oriented, well ... Now, whom it satisfies, well, > that's > another question. You're stating that procedure orientation and goal orientation are the same thing...? >> This is tickling a vague and disturbing memory. Maybe nine years >> ago, someone on the classiccmp list loudly made the absurd assertion >> that "only 5% of software development is writing code". I responded >> by stating that that person would never, ever work for me. Was that >> you? >> > Very possibly, but the 5% includes design, development, and debugging. > Analysis, reviews, and documentation precede that task, and consume > most of > the remaining 90%, with at least 5% for rigorous testing. I agree > that M$ > doesn't do the testing. Yup, it was you, in December of 2001...I just found it in the classiccmp archives. Here is your exact statement from that thread: "Well, perhaps the reason for all the meetings and other work you find uninteresting is that it's necessary to arrive at a firm specification for what you have to build before you go off and build it. Since the coding, compiling, and debugging only represent about 5% of the task, the bulk of the work has to happen sometime, and that's what the "other" stuff is." I'm truly glad the world doesn't actually work that way. I'm tired of suggesting that you go write some code. Why don't you go have a meeting or something, and *I* will go write some code. It has become clear that you've become too mired in your procedures to ever get around to it. G'night. -Dave > -- Dave McGuire Port Charlotte, FL |