Request: Enhancement in Use of Account Codes

Mike or Penny Novack stepbystepfarm at mtdata.com
Thu Dec 25 14:56:40 EST 2008


>  I am not sure your experiences, the analytical approach, division of labor (hats as you described them) which I would consider best practice in any kind of business project can easily be transferred to gnucash or any other FOSS project.
>  
>
  The only real difference is that it's voluntary. Nobody paying the 
bills and so nobody in a position to say "do thus and so". I agree with 
you very much that I do not see "standard software development process" 
being used in FOSS. Could that the the reason for some of the problems?

  User expectations? My sense is that users do not seem to understand 
their role in the process. When I was PAID to do this sort of work, I 
might have had to tolerate a user who wasn't willing at first to do more 
than tell me "it's broken, fix it". In other words, my job to help this 
user and so would devote as much time in as many meetings as necessary 
to tease out what the users ACTUALLY need till there was a clear 
understanding of what the darned thing was SUPPOSED to do. I certainly 
wouldn't bother to take a look at the code until that was out of the way.

   Unless there is a clear understanding of what the program is supposed 
to be doing DIFFERENTLY, it ain't broke. It's working perfectly well 
(doing whatever it does) right now. I'm an analyst, not a mind reader, 
can't "guess" what it is that the users really want/need (often NOT what 
they initially say that they want/need).

>I've never seen you around before, but you seem to have valuable 
>knowledge.  What is it that you are suggesting and what role do you see 
>for yourself in that?  How long have you actually been following what is 
>going on with gnucash development?
>
    Almost two years. Had a house fire November 2006 which took out the 
hardware and software on which the organizational books were kept. At 
the same time as reconstructing the books the old fashioned way on 
paper, began a parallel with GnuCash, and recommended adoption of this 
software instead of replacing the commercial package. In terms of 
standard bookkeeping (auto posting ledger) I've never had the slightest 
problem with GnuCash except for the annoyance of not being able to set 
up properly under all legal Windows* user names.

   I've been watching both the user and developer lists since, and 
consider that my professional expertise should be available to the 
project. I've done a few hundred thousand lines of code in my day, all 
in "financial applications". Never worked in any of the languages 
GnuCash is in but that's not really relevant (not when you are fluent 
writing in half a dozen and can read most anything -- pretty fast to add 
one more).

   Anyway, I don't see the real bar to getting things done to be lack of 
programmer availability as much as the lack of user commitment to do 
their part of the process. I've seen lots of complaints "doesn't do this 
or that" but not one presentation of a "business spec" of what a group 
of users would want differently. Complaints that the the programming 
developers aren't doing their job misunderstands the problem. They 
aren't being given a clearly defined proposal.

   Thus --- asking "please have GnuCash create the xyz report such that 
it meets county C's reporting requirements" is NOT how you properly 
frame a request to a programmer. It's not the programmer's job to look 
up the regs of country CD and find sample reports meeting these regs, 
etc. That's the user's job, assisted by the "business analyst" (who 
might not initially know the answers but knows how to tease those out of 
the users). Very important to have all the loose ends defined, because 
in reality, perhaps 80% of the coding of any real life software project 
is dealing with the exceptional conditions the end user doesn't even 
think of as potentially existing (unitl the business analyst begins 
asking questons).

Michael D Novack, FLMI


* That I might be perfectly happy running under a 'nix OS besides the 
point. Only one other board member of one organization and none on the 
boards of any of the others would, so software caapble of running under 
Windows a must. Might not always be treasurer.


More information about the gnucash-devel mailing list