Spam:****, Re: Profit and Loss Statement for Closed Books

[Derek Atkins]

Colin,

"Colin Scott" <gnucash at double-bars.net> writes:

>> The issue here is that the reports are a conglomeration and
>> accretion over time.  Then new features get added, but that does not
>> mean that developers go back over all the reports to make sure each
>> one "works" with the new features.  This is a lot of work, so it
>> falls by the wayside when other progress is made.
>> 
>
>
> Even though the report set "just growed", as you describe, there is
> little reason not to ensure that the operation and output of a new
> report conforms more or less with the operation and output of those
> preceding it.  Thus I would expect there to be standardised sets of
> parameters(eg, to include account filter selection) standardised
> facilities (eg, sub-totalling, grand-totalling, etc etc) and
> standardised output formats (eg, standard notation for column breaks,
> page headers and footers including things like report title and
> date(s), and page numbering in the form "<page number> of <n> pages")
> I'm not suggesting that all new features/facilities should be
> retro-fitted as they appear, but that they *should* be fitted in all
> subsequent new reports, and whenever a significantly revised version
> of a report is produced.

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.

>> Are you offering to go and test each report against each new 
>> feature to make sure it "works correctly"?
>
> No.  No more, I would guess, than you are suggesting that those
> contributing reports, and those accepting them for release, don't test
> that the features used actually work ...  :-)

See, we're talking about apples and kumquats here.  The issue here is
that adding new features can often create a regression in an existing
report.  Absolutely *new* reports are tested before they get added, but
reports are the end consumer here.  Additional features below the
reports can (and have) cause(d) regressions in reports, but alas we do
not have a test harness that can recognize it.  And asking a developer
to test each and every report is too cumbersome.

So what happens is that new features get added and the reports wait
until someone notices there is a problem, at which point it hopefully
gets fixed.

In this case, it got fixed in some reports, but not all -- because the
report infrastructure isn't really designed well to allow a write-once,
fix-everywhere application to reports.

You're welcome to get your elbows dirty and help out, but complaining
here isn't doing anyone any good.

> Colin

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available