Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: >> I agree, but OTOH there is a line of thought that claims that >> development is more focused and efficient if you document first what >> the code that you are going to write is supposed to do. > I'd tend to argue that formal documentation should follow code not > precede it - development is often quite fluid (I'll usually try a couple > of approaches before settling on a solution, or, in the rename case, > about 50 different ones...). There are probably good examples for both. For example with the rename case, there are probably a number of things that should happen, a number of things that may happen (and that have different trade-offs) and a number of things that should not happen. Having a clear view of all these probably helps before coding -- and writing this down may help to make it clear. (Notwithstanding the fact that the view of these probably changes somewhat during coding.) > Ideally there'd be someone to sign off bugs onto as well as the > developer who fixed it is never the person who should be testing fixes.. Definitely... :) The developer of course only tests against the cases he already took into consideration. The most he can find is when his code doesn't behave according to his use cases. Whether these are too limited he may not ever find out. > Once we get a second developer we can pass bugs to each other and at > least have a verification system Probably in this case, you'd have to have documented how a feature should /exactly/ work by the time it should get tested, or else the other person doesn't really know what to test for. Which means that the documentation goes very closely hand in hand with the code -- whether before or afterwards. > (in a company you'd have a third - the reporter - but that's not so easy > in opensource). You're probably talking about the noise in a bug database with public report access. That's really sad, because one would think that open source would actually make this easier, with having many more reporters. Gerhard