Thorsten Behrens wrote: > Mathias Bauer <[EMAIL PROTECTED]> writes: > >> Not exclusively. Also developers will benefit from a spec if they have >> to refactor/change/extend the code later on. Believe me, I can't count >> the occasions any more where I would have been glad to have a >> specification for a feature that needed a larger rework. Without a spec >> we very often are standing in the dark and hope to be lucky not to >> damage too much things just because we just don't know about their >> existence. >> > Hi Mathias, > > yes, you might catch a few bugs using this approach. But I think one > of the key messages of agile software engineering is that in the end, > the code determines behaviour, not documentation. Put differently, > code and documentation will quickly diverge, simply because there > can't be technical, automated means to check that they are in > sync. This answer is typically for the whole thread. We (including myself) mix too many things into each other. IMHO it is undoubtfull correct that a spec has the value I described, even if it is not completely in sync with every detail of the code.
And it is also undoubtfull that specs tend to get out of sync with the code if you don't fight against this tendency. And it has happened for a lot of specs already (to a different degree). But both facts don't mean that either specs are useless at all or OTOH specs are the greatest thing on earth and so everybody (even the development noob) must provide one for even trivial "features" before he gets his entry to the holy of holies. I start to subscribe to your idea of lowering the burden for new developers - not by dropping our requirements for some kind of documentation but by making the process more "agile" and light weight and also putting some work on the shoulders of the project members or even project leads. But not because I think that we are doing something wrong now (from a technical or project management POV) but because I think that if specs are an important barrier to contribution we must do something to lower or remove this barrier. If this created some problems or a little more work for others we would have to names these problems and additional duties and decide what is more important for us: avoiding them or lowering the barriers to contribution. In my understanding community building and fostering community based development is one of our most important goals and so this deserves some compromises elsewhere. I still want paid or even long term non-paid developers (not only Sun developers!) to stick to our rules. I'm also for more agility and usage of common sense in the application of them, but not as a creeping undermining. This is something we must agree upon beforehand (and we comprises not only development but also QA, Documentation etc.). Until then we should stick to the current way of doing things. I think it's time for a summary. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
