> >My understanding for the reason of the current situation is that there >is nobody fitting all of the following description. > >1) can code >2) has time to contribute code >3) business user >4) lives in Europe > >I fit 3 and 4. I currently think that trying to get gnucash into shape >for business users is unlikely to happen even in the medium term. I use >gnucash when it is the right tool and thank Phil for providing us with >the SQL backend which then allows me to access the accounting data for >reporting and manipulation from other SQL tools. AFAICS, it currently >is the only sane way to handle this. > > IMHO you do not want "a person" who meets all those criteria. And the additional criteria "can design" (not the same as coding) and "can test/has time to test". Those criteria define the TEAM you want to assemble. Some of the hats can be worn by the same person but it is actually a rather bad idea if one person is doing the whole thing.
Unless a program hangs or loops, if what it is SUPPOSED to do has not been properly specified, then it must be doing the "right thing" (whatever behavior it exhibits is what it does, there is no outside criteria of "rightness". The business USER in conjunction with a BUSINESS ANALYST constructs the "requirements" (definition of what is needed). Alone the USER is unlikely to consider all the "rare situations" since from an end user point of view, what a system usually does is what is in their mind. The SYSTEM ANALYST in conjunction with the BUSINESS ANALYST designs the system. The PROGRAMMER in conjunction with the SYSTEM S ANALYST implements the program. The TESTERS in conjunction with the PROGRAMMER test the system according to the test plans devised by the BUSINESS ANALYST and SYSTEMS ANALYST and the USER usually is involved too (but in MY work, I would have been embarrassed if the user ever got to see something not working correctly; that final sign off should be a formality of the other "pros" have done their jobs). I do not mean to imply it has to be formal titles or different people -- but these are "hats", many of which I have worn, sometimes several on the same project but that's not easy or the safest thing to do. While wearing one hat must somehow keep from considering the problem too much from the other person's point of view (when designing, should NOT be thinking "how am I going to code that?"). Only to the extent necessary (when coding, always thinking what test data/process will be necessary to test every bit of logic -- perhaps building the test processes at the same time as the main program). Michael D Novack, FLMI _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
