| ??? 04/12/12 16:23 Read: times |
#187108 - be careful ... Responding to: ???'s previous message |
Erik Malund said:
Yourdon .... They were both popular back in the early '80's, as they had figured out that you can't code what you haven't designed, just as you can't measure what you haven't built.
I had Yourdons first book as manuscript and I recall a quote: "after several years of experience most programmers realize that the most important quality of a program is that it works." It's hard to interpret this comment without falling into the trap that you, yourself have pointed out. It all comes down to the definition you use for "works." As I'm sure you're aware, it's possible to have something "working" for a long time, until you discover that it isn't doing what it should do, though it appears to do that much of the time. The key is a program must do what it is required to do, and never do anything else. If you follow the methodology promoted by these two old-timers, and I'm of similar vintage and background, the principal assertion they both make is that you have to define the requirements before you can enter the design phase. There's a whole set of industry practices that's based on that notion, and nearly all major projects in both hardware and software have been developed in accordance with that methodology. the most important.... do, you see 'documentation' in that paragraph? How you record your efforts and what you call it is up to you. Nevertheless, and we're discussing a major piece of work (LINUX) here, involving multiple participants, and, in order to get everyone onto the same page, people have to have it written on the same page. and I the quote you post the word is NOT 'documented' but 'designed' there is an ocean of difference. Well, perhaps you can explain how you can "design" something before you define it. I admit that if the effort is performed by one or a very few participants, you can "get by" with meetings and iron our the wrinkles that result from such practice by having further discussion, but once you have multiple participants, in multiple locations, at multiple times, all attempting to produce a single work-product, things have to be formalized in writing. no, I am, by no means, adverse to documentation, but I take exception to your postulate that everything can be documented fully before any code is written.
Erik I have difficulty following your rationale. How can you code something that hasn't been completely defined, the requirements for which haven't been analyzed and decomposed in to their elements, and for which clear criteria haven't been devised? How can you rigorously demonstrate that your end-product "works" if you haven't devised a test plan that not only demonstrates that all the requirements are met, but how far they can be pushed before failure occurs? How can you predict what will happen to the system when a failure does occur? In fact, how can you define a failure before you completely define what "works" means? RE |
