Profit and Loss Statement for Closed Books

[John Layman]

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?

To what extent is the value of GnuCash tied to whether or not someone finds
value in using it?

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?

What are the ethics of releasing versions you are unable to fully support?

Is it professional and ethical to shrug off defects unintentionally
introduced via code change and attach no priority to correcting the issues
thus created?

What is the relative importance of refining and enhancing the product versus
refining and improving the development process?

If leaks are appearing in the dike, does an appeal for more hands to poke
fingers in the holes get at the root cause of the problem?

What level of peer review is directed to ensuring architectural integrity
and consistency of usability traits?


I throw out these questions because there appears to be an ideology at work
among (at least some) of the development team that is unlikely to make the
product a success in the long haul.  GnuCash shows signs of brilliance, and
the scope of its features is perhaps better suited to the user who needs to
do both personal and business bookkeeping than any alternative currently
available.  Still, GnuCash has a great many rough edges, it's built on dated
technology, and it competes for its user base against a flood of new
offerings in the cloud.  IMO, none of these new offerings measures up -- for
now -- but they exhibit brilliance in their own right and show every promise
of evolving to the point that they'll be able to run GnuCash right off the
road.  If all value is ultimately use-value, then the value of GnuCash lies
entirely in its user-base, and the size of that user-base depends upon how
successfully GnuCash provides "quality to some person".  If "some person" is
limited to the circle of developers itself, then GnuCash is just a lab
experiment.


-----Original Message-----
From: gnucash-user-bounces+john.layman=laymanandlayman.com at gnucash.org
[mailto:gnucash-user-bounces+john.layman=laymanandlayman.com at gnucash.org] On
Behalf Of Colin Scott
Sent: Sunday, March 25, 2012 10:29 AM
To: warlord at MIT.EDU
Cc: gnucash-user at gnucash.org
Subject: Re: Profit and Loss Statement for Closed Books


> While I appreciate your point of view, when someone is adding a 
> feature to the main code it's a chore to go and test every report to 
> see if the new feature affected the output of the report.  The 
> feature-writer may not even *use* some of the reports, so may not even 
> know what the report output was supposed to be.

I must confess to being a trifle bemused by your point, which seems to imply
a lack of modular design (or failures in modular design) that I frankly find
pretty hard to believe.  I would expect, for example and as a matter of good
design, account selection to be completely standard, fully tested, and
available as a simple plug-in function.  If it works in one report, it
should work in all of them - were it otherwise I should consider there to be
a serious flaw in the design or implementation of that feature!  Similarly,
I would expect basic data retrieval for those selected accounts  also to be
available as a standard, tested, plug-in function.  

I will admit that I have never worked on open-source development, but I
cannot see how any significant project could be conceived were such basic
concepts of modular design not incorporated at an early stage.  And yes, of
course, even good modular design isn't a magic bullet, but that and proper
testing do make software more robust and less prone to regressions, and
generally makes the regressions that might occur easier to track and fix.

> You're welcome to get your elbows dirty and help out,

I would be delighted to do so, but I must confess that my skills, such as
they were, and my brain, are probably too rusty to revive sufficently for me
to grapple effectvely with a completely new language like guile/eguile.
Now, were the SQL database to make the data available in some suitably
rational form then I might well be able to revive my Perl and SQL skills
sufficiently to make a modest contribution (always assuming no religious
objections to Perl within the gnucash world!  :-)  However, my attempts to
build a set of basic views to enable access to the data in the fairly
simple-minded way that I (and reports!) would ideally need have so far been
less than successful.

> but complaining here isn't doing anyone any good.

I would hope that all participants in the gnucash project would be open to
views expressed in here.  They may not agree with them, and they may not
feel able to do anything about them in the short term even if they do, but I
would expect user views expressed in here to have some affect on the
development priorities and direction of the project in the longer term.  (Of
course, views conflict, so some would win and others lose in this process.)
In any case, to expect everyone expressing a view to do it themselves is, in
my view, even less reasonable than to expect an expressed view to be taken
up and actioned instantly ...

Colin
_______________________________________________
gnucash-user mailing list
gnucash-user at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.