David Megginson writes: > > I am willing to accept a little lag but one can of course take the > > 'exteme-programming' approach of writing the documentation > > first before you code :-) > > Actually, they write the unit tests before they code. Kent Beck, at > least, doesn't seem to be a big fan of detailed documentation.
This could take us down the road towards a discussion of underlying philosophies of software engineering. I took my software engineering class back in the late 80's when everyone was young and idealistic and before open-source really took off. I was always taught: 1) Make a requirements specification 2) Make a perfect and complete design (implies documentation could or should be written at this point), 3) Impliment, 4) Test. When you finish one of these steps, you move forward and never go back (too costly and time-consuming to back track and redo.) If things went astray in this process, then obviously you didn't do 1) or 2) correctly. Either you are a screw up or you need a better design methology to follow. Obviously no one wants to be a screw up so we need to think up better methodologies to follow to help us do a perfect requirements spec and design up front. I was taught several goofy methologies that I have always ignored because they seemed exceedingly lame. :-) The underlying fear is that the later a bug or insufficiency is discovered in the process, the more costly it is to fix. That is still true, but ... It's really really hard to do a perfect design up front that encompases every future whim of your customer. In fact, beyond trivial class room examples and maybe a few rare cases when all the planets line up, I'd argue that it is impossible to do a perfect requirements spec and perfect design before any coding happens. My inside sources tell me that these days people in software engineering classes are thinking about a "spiral" approach. You still have the same basic steps of doing a requirements spec, design, impliment, test. But you permit yourself to iterate through the steps and refine them as many times as it takes ... spiraling slowly towards the finished product. The assumption here is that we probably have to give up on the idea of doing a perfect design up front ... that has similar difficulties and challenges to predicting the future. There are some things we can predict pretty reliably (ie. the sunrise) but usually the things we want/need to predict are a lot more complex than that. Instead you do the best you can at each stage understanding that you will undoubtedly return to rework or refine the requirements spec and design and implimentation ... probably many times. To me this sounds a lot like what people often fall into naturally with open-source software development projects. Of course, what I was taught isn't complete bunk; the better job you do at each stage (even if you plan to return and refine later) the more quickly you arrive at a correct and finished product. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
