Mathias Bauer <[EMAIL PROTECTED]> writes: > 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. > >> > > 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. > Moin Mathias,
right - you are stressing the fact that specs are useful (which I conceded further down in the same posting), I'm saying that they don't solve the root cause of the problem you were describing. We seem to agree. > 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. > Cool! I guess this is all that's needed here. Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
