[thelist] Representing tasks in the database

[Luther, Ron]

Hi Matt!   Hi Joel!


Just chiming to agree ... but also to note that 'scope' can be another
factor in creating these kinds of situations.

As Matt correctly noted, these issues can arise over 'time' as
dependencies are added to complex systems by later staff who don't fully
comprehend all of the existing dependencies and interactions.  Heck, in
some organizations many of those other dependencies may be managed by
other groups!  ;-)  It's big fun!

These issues can also arise across 'scope'.  A system containing
dependencies to kick off batch jobs at 3:15am, for example, a system
that works "just fine" in California or across the US can suddenly
develop issues when rolled out on servers world-wide.  Can't imagine
why.  There isn't even any error in the program logic.  Well, not 'per
se' anyway.  The underlying (and in this case unspoken) system
assumptions for scope have changed.  

Another side of the 'scope' coin comes up when you combine systems or
projects that were developed from different points of view.  Just
because a warehouse manager wants to keep track of his shipments to
other warehouses 'in support of customer orders' separately from his
other shipments does not mean that those shipments should be counted as
'customer order shipments' when you roll up all shipments to a
world-wide corporate view.  That isn't to say that the warehouse manager
is wrong.  He's looking for a P/L on his own operations.  But from
different perspectives, those shipments may be counted in different ways
for different levels of P/L aggregation.  Blindly combining business
logic as systems grow beyond their initial scope can lead to these kinds
of problems.



[Also, speaking of scope yet again --- I think some folks following this
thread may be thinking only of cases where the logic affects every
single record being processed or a very high percentage of those records
or that these errors always cause a process or program to abend with
alarms and BSODs and hex dumps and things of that sort alerting the
world that there *is* a problem.  I think things are usually more
insidious.  What I usually run into are the 'edge cases' where a
business process change causes this kind of situation to occur for some
very very small percentage of transactions and even in those
transactions merely causes the data to be incorrect.  No systems fail.
No error messages get logged.  No support folk get paged out in the
middle of the night.  In these cases I often have a heck of a time
convincing the appropriate group that some code needs to be rewritten
and corrected.]

HTH,
RonL.
Chief 'Insidious Case' Finder