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.
Gerhard Fiedler 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 tend to agree with that, even > though I know many of my clients don't... :) 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...). In a team situation you'd have a level of documentation that meant everyone knew what they were supposed to be doing, at least to a general level. I'm against the whole concept of 'status meetings' though (in the last place I worked we spent a total of 2 days a week in meetings, often being berated about how development was falling behind....) OTOH cvsnt development is still basically me at the moment, and there aren't the team issues.. I know what I'm doing so can get away with jotted notes plus the long term plan (which is a written document, written a while ago around the time the commercial support started). There's a fair bit of discussion behind the scenes about priorities with the commercial side of march hare, although even that can change (I hadn't planned to spend so much time on 2.5.01, the issue system, etc. and these caused 2.5.02 work to slip). 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.. as is evident from recent snafus eg. add -r. Once we get a second developer we can pass bugs to each other and at least have a verification system (in a company you'd have a third - the reporter - but that's not so easy in opensource). Tony