Request: Enhancement in Use of Account Codes

[Mike or Penny Novack]

>
>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