Profit and Loss Statement for Closed Books

[John Layman]

Whoops, make that "many-to-one" relationship...

-----Original Message-----
From: John Layman [mailto:john.layman at laymanandlayman.com] 
Sent: Monday, March 26, 2012 3:20 PM
To: 'stepbystepfarm at mtdata.com'
Cc: 'gnucash at double-bars.net'; 'warlord at MIT.EDU'; 'gnucash-user at gnucash.org'
Subject: RE: Profit and Loss Statement for Closed Books

> MOST complaints I have seen are not useful.

I didn't post rhetorical questions with the aim of spawning general
discussion here, but I have a reaction to what you've written.   First of
all, commercial software products produce a flood of problem reports that
aren't necessarily accurate or useful.  They usually require some
investigation and verification before a report can be considered a
legitimate incident.  Incidents themselves require investigation to
determine if there is commonality with other reported incidents.
Ultimately, there is likely a one-to-many relationship between reported
incidents and an issue to be resolved.  That issue is the "bug" and the root
cause may not be known.  Regardless of whether you term the original reports
to be "problem reports" or "complaints" it is short-sighted to say they are
not useful.  They represent data and are therefore measurable.  Measuring
what you are receiving in the complaint department is a pretty fundamental
aspect of managing anything that serves a customer.  Even when someone
reports simply that something doesn't work, and you know full well  that it
does, the report is not without significance.  The measurable volume of such
reports can serve to tell you it isn't obvious to users HOW that something
works.

It's problematic to declare open season on the bug tracker, because you
quickly get a database filled with such a flood of unclassified, unverified
reports that the tracker can be almost useless.  Unless you tame this
process, you soon have a situation where users don't bother submitting
problem reports and developers pay no heed to the reports they have.





-----Original Message-----
From: Mike or Penny Novack [mailto:stepbystepfarm at mtdata.com]
Sent: Monday, March 26, 2012 1:36 PM
To: john.layman at laymanandlayman.com
Cc: gnucash at double-bars.net; warlord at MIT.EDU; gnucash-user at gnucash.org
Subject: Re: Profit and Loss Statement for Closed Books

John Layman wrote:

>I think it would be well for the development team to reflect on a few 
>rhetorical questions.
>
>What is the real purpose of this development undertaking?
>
>Is there no conceptual 'customer' (other than the development cadre
>itself) that guides the course of development?
>  
>
There is (or should be) a conceptual customer

>
>If the real value of GnuCash is use-value, what importance attaches to 
>feedback from its users (both positive and negative)?
>
>Is it realistic to suppose that all users of the software will have the 
>time or ability to participate in supporting the effort in some way?
>  
>
OK --- let me express a strong opinion here based upon decades in the cypher
mines. There is a problem because of the lack of USEFUL user participation.
Unless there is clear input from users AND commitment to the testing process
........
1) A program is "correct" if it doesn't hang or loop. Unless there is a
definition of what it is SUPPOSED to do then whatever it does is correct
(with the exceptions noted).
2) It is up to users to be helpful here. I am going to point out that the
reason I am not actively designing and coding for this sort of project is
that there is little to no user participation filling the development roles
that are up to users .About 20% of the effort (in the "real world") is USER
time coming up with specifications, the user test plan, and users committed
to do that.

MOST complaints I have seen are not useful. If all the complaining user is
willing to do is report "it doesn't work" (which may or may not be
true) but not commit to working with a developer to get to the bottom of
whether there really is a problem and then the work of fixing it (the user
to determine IF has been fixed) then this is not useful and probably why
being ignored. It is certainly why I (a potential
developer) am ignoring the situation. I also wear a user hat but I am NOT
encountering the same sort of problems. Gnucash does accounting for me just
fine, thank you.

Developing software is NOT just for us analysts/programmers.

Michael D Novack, FLMI