[lmi-commits] [6442] Draw lessons from recent experience: inforce less than one month

[Greg Chicares]

Revision: 6442
          http://svn.sv.gnu.org/viewvc/?view=rev&root=lmi&revision=6442
Author:   chicares
Date:     2015-12-13 13:44:26 +0000 (Sun, 13 Dec 2015)
Log Message:
-----------
Draw lessons from recent experience: inforce less than one month

Modified Paths:
--------------
    lmi/trunk/ChangeLog
    lmi/trunk/DefectLog

Modified: lmi/trunk/ChangeLog
===================================================================
--- lmi/trunk/ChangeLog 2015-12-12 16:00:25 UTC (rev 6441)
+++ lmi/trunk/ChangeLog 2015-12-13 13:44:26 UTC (rev 6442)
@@ -37727,3 +37727,8 @@
 Revise the 20151210T2158Z change. See:
   http://lists.nongnu.org/archive/html/lmi/2015-12/msg00006.html
 
+20151213T1344Z <address@hidden> [456]
+
+  DefectLog
+Draw lessons from recent experience: inforce less than one month.
+

Modified: lmi/trunk/DefectLog
===================================================================
--- lmi/trunk/DefectLog 2015-12-12 16:00:25 UTC (rev 6441)
+++ lmi/trunk/DefectLog 2015-12-13 13:44:26 UTC (rev 6442)
@@ -39,7 +39,7 @@
 [ 8] Provident safeguards: [what prevented more severe damage?]
 [ 9] Similar defects elsewhere:
 [10] Critique of the past: [how could this have been avoided?]
-[11] Watchwords for the future:
+[11] Watchwords for the future: [how will next time be different?]
 [12] Person-hours spent on diagnosis and repair:
 [13] Automated tests: [were there any before? have any been added?]
 [14] Repairs completed: [cite 'ChangeLog'; summarize if not obvious]
@@ -603,3 +603,131 @@
 today is to fix a regression error; the two hundred or so taxation
 issues mentioned above are as yet unaddressed.
 
+20151213T1344Z <address@hidden>
+
+Symptom: Decrementing a new-business illustration's effective date
+flags it as inforce and prevents re-editing it.
+
+To reproduce with HEAD as of 20151107T1344Z:
+
+  File | New | Illustration
+  subtract one day from "Effective date"
+  OK
+  Illustration | Edit cell... [fails irrecoverably]
+
+If a full month is instead subtracted, a blank illustration is
+produced; such a case can be saved and reopened, but fixing it
+is difficult or impossible.
+
+Discovered: By tester, while validating a monthly distribution.
+Reported 20151120T1938Z; symptom suppressed 20151123T1647Z, before
+release, so users were not exposed to the reported symptom.
+
+Location: Diagnostics added 20151106T1911Z...
+  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/input_harmonization.cpp?root=lmi&r1=6354&r2=6388&diff_format=u
+
+|    if
+|        (  EffectiveDate.value() != InforceAsOfDate.value()
+|        && (0 == InforceYear && 0 == InforceMonth)
+|        )
+|        {
+|        fatal_error()
+|            << "Inforce illustrations not permitted during month of issue."
+|            << LMI_FLUSH
+|            ;
+|        }
+
+...and 20151107T1344Z:
+  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/ledger_invariant.cpp?root=lmi&r1=6317&r2=6394&diff_format=u
+
+Premonitory defect markers: A "code smell" was noted weeks earlier and
+discussed on the mailing list (q.v.):
+
+  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/ledger_invariant.cpp?revision=6394&root=lmi&view=markup
+|    // Dubious--see:
+|    //   http://lists.nongnu.org/archive/html/lmi/2015-09/msg00017.html
+|    IsInforce = 0 != b->yare_input_.InforceYear || 0 != 
b->yare_input_.InforceMonth;
+
+Cause: The proximate cause is that new diagnostics trapped a latent
+error, imposing an obstacle for users. The ultimate cause is what the
+diagnostics declare: decrementing the effective date transforms a new-
+business illustration into an inforce illustration...because inforce
+dates are not decremented in lockstep.
+
+Genesis: Introduced 20090526T1331Z (revision 4599) in a redesign, with
+commit message "Use dates instead of durations for inforce". Older
+versions captured only inforce year and month, which retain their
+meaning when effective date changes. This redesign introduced a field
+for inforce date, which retains its value and loses its meaning when
+effective date decreases: new business becomes inforce accidentally.
+
+Inforce date is constrained to be no earlier than effective date, so
+increasing the effective date can't produce this problem.
+
+Provident safeguards: An unannounced '--pyx=off_monthiversary' option
+was provided to sidestep some of the added diagnostics for inforce
+extracts, where errors (off-monthiversary extracts) were anticipated.
+This option deliberately did not override the diagnostics blocking
+inforce illustrations in the month of issue, because that is a graver
+error than specifying the wrong date in an inforce extract.
+
+Current home-office users have access to inforce inputs, and can force
+the dates to align. However, field users (and, soon, new home-office
+users) don't have those input fields and can't fix the problem.
+
+The new diagnostics were added 20151106T1911Z and 20151107T1344Z,
+early in the monthly cycle to allow plenty of time for testing.
+
+Advancing the effective date by a month or more generally causes an
+empty illustration to be produced; perhaps that is rare, because no
+end user complained in the six and a half years this latent problem
+existed. Advancing it by less than one month may, through sheer luck,
+produce a valid illustration, although it is difficult to prove that
+this was always the case because the code (since redesigned) was so
+complex. Illustrations affected by this anomaly were self-consistent;
+they just weren't what the user intended.
+
+Similar defects elsewhere: None. The original motivation for this set
+of changes is that some code deemed an illustration to be inforce if
+effective date and inforce date were unequal, while other code checked
+whether inforce year and month were both zero. Those differences were
+systematically removed, and all code now compares the dates (which are
+the actual input).
+
+Critique of the past: Ramifications of the 2009 redesign should have
+been considered more carefully and thoroughly. Last-minute changes in
+business requirements left insufficient time to fix the real defect
+once it was exposed, forcing time to be spent on temporary mitigation
+of side effects of the new diagnostics.
+
+Watchwords for the future: Trying to accomplish the same thing by
+different methods in various places is a code smell. Explicitly
+validating the assumptions implicit in old code (e.g., that different
+methods have the same effect) is a profitable activity. Defects whose
+exposure is anticipated (known unknowns) may be less interesting than
+those actually exposed (unknown unknowns).
+
+Person-hours spent on diagnosis and repair: eighteen so far, but the
+underlying problem remains.
+
+Automated tests: The reported symptom arose from internal consistency
+checks that were added only recently. Adding a unit test to "verify"
+that these checks work would amount to closing the stable door after
+the horse has bolted.
+
+Repairs completed: Suppressed these inconvenient diagnostics on
+20151123T1647Z, for new business only. This is a regrettable stopgap:
+the new diagnostics really would prevent users from running unintended
+inforce illustrations.
+
+Repairs postponed: Repair of the actual problem has not yet begun due
+to other urgent priorities. One idea: add a "this-case-is-inforce"
+checkbox; if it's unchecked, then inforce as-of date and last material
+change date move in lockstep with effective date. When that's done,
+'--pyx=off_monthiversary' should be removed. Also consider removing
+'InforceYear' and 'InforceMonth', or at least making them text rather
+than spin controls.
+
+These diagnostics showed that one of our regression tests has always
+been invalid; it has not yet been fixed.
+