Re: Here's one problem
- From: docdwarf@xxxxxxxxx ()
- Date: Fri, 26 Sep 2008 13:22:16 +0000 (UTC)
In article <dabod4pgnntf1ukd1kgthlcslarsf267cb@xxxxxxx>,
Robert <no@xxxxxx> wrote:
On Thu, 25 Sep 2008 10:28:45 -0500, "HeyBub" <heybub@xxxxxxxxxxxxxxx> wrote:
"Functional Indeterminacy Theorem (F.I.T)
In complex systems, malfunction and even total nonfunction may not be
detectable for long periods, if ever. Such systems may, however, persist
indefinitely or even expand."
Worse, the system RESISTS correcting errors that are discovered and
reported. I often see
errors so obvious, they leap out of source code.
Mr Wagner, leaving aside the fact that 'obvious is in the mind of the
beholder' and that what you bring to an organisation is a different
mind... you might do well to remember your Elementary Physics.
Newton's First Law is that 'an object perserveres in its state of rest or
uniformly straightforward motion except as it is forced to change its
state by another impressed force'.
(the Latin is lovely; 'Corpus omne perseverare in statu suo' can be
readily punned into 'Omne preseverare in status quo')
When a change in motion is sought two things must be remembered: the
original force compelling the motion, by Law cited above, will resist this
change and force must be applied. Human beings, at times, do not respond
well to being subject to force... but that's sociology, not physics.
Me: This is a bug. It's not setting the price plan on a cancellation reversal.
Colleague: I never thought of that. Tell the boss.
Obviously an organisation which does not reward the behavior of 'notice
what appears to be an error, change the code, notify the boss'.
First line of defense: Denial
Manager: That code has been in production for years. Nobody has
complained. It must not
happen the way you say.
Me: I set up a test case. Here, you can see it happening.
Manager: Sure, you made it happen. Has it ever happened in the real world?
I'll try to avoid the check-list of a psychiatrist, Mr Wagner, and stick
to the languages of harder sciences. You present an observation ('the
code will do (x)') and generate a series of conditions which confirm your
observation. The Manager questions whether the series of conditions you
contrived are representative of Business As She Is Done.
(Two hours research, searching millions of archived transactions.)
This is one reason of many for avoiding the Kubler-Ross model... not only
was the experiment acceptable as basis for further questioning ('has it
ever happened in the real world?') but time - both human and machine -
were allowed to be used in further research.
(I am assuming that you did not do this research on your own free time, of
course... and if the company did not freely allow you use of its own
resources (CPU-time and XIOs cost money, you know) then I question the
rationality of working with an organisation that demands you steal from it
in order to try to save it money.)
Second line of defense: Minimizing
Me: Here are five examples that happened yesterday.
Manager: How much could we have lost, maybe twenty dollars on each,
tops. You want to
spend a thousand dollars to recover less than a hundred?
Me: It happened five times yesterday. This year, it's happened 1,623 times.
This, I would say, reflects more on the presentation of the data. First
the sample size and timeline, *then* the analyses of frequency, severity
and cost. 'Five times yesterday'... those who have participated in a 'go
live' or two, or seen a few divisions/corporations absorbed/spun off,
might see that all 'yesteredays' are not equal.
'1,623 times' is also another imprecise statement. 'Millions of archived
transactions'... assuming two million then 1,623 errors is an
accuracy-rate of over 99%. What kind of transaction-costs are involved?
Not all widgets are the same, shoelaces are not steamships. Stating the
'Given an analysis of (n) transactions over (period) there were found to
be (m) transactions showing the error noted. Total costs for all errors
to the company were (US$X), with an average cost of (US$Y) and a median
cost of (US$Z).'
This is not bargaining with God or playing chess with the Grim Reaper, it
is supplying data upon which a more financially-sound course of action
might be based. Given (what it costs) and (what it will cost to
repair)... is it worth it?
This isn't rocket surgery... errrrr... brain science... errrrrrr... you
don't need to be the sharpest knife in the chandelier to play this game.
(note to those unfamiliar with colloquial American English: if the above
needs explaining please ask)
Third line of defense: Blame Others
Manager: We did what the customer asked for. It says right here in the
High Level Design
that we should convert the New Business to a Cancellation Reversal.
Me: The customer didn't tell us to ignore the new price plan.
Manager: Well, they didn't tell us to pick it up, either.
Me: The customer didn't write the High Level Design, we did.
Manager: The customer signed off on it. And they didn't catch it during UAT.
If it is costing the company sufficient money as to merit correction it
might, given a statement of costs, be corrected.
If it is costing the customer money AND IS WITHIN THE LAW... then it
becomes a question of tangible versus intangible costs.
If it is costing the customer money AND IS ILLEGAL... then a lot of
possibilities open up.
(One of these possibilities could be for you, as the one who discovered
that the company's 'previously undetected' (quotation marks intentional)
illict actions, to hire someone to start your car in the morning because
someone from Corporate is going to wire it to explode.)
Fourth line of defense: Bargaining
Me: Let's call the customer and ask what we should be doing.
Manager: That'll open a can of worms. They'll want us to compute
adjustments for the last
year. What would it take to fix it quietly?
Me: One line of code, in a program we're already changing.
Manager: Just do it and don't discuss it with the customer.
Refinement of a process so that it requires the least amount of energy in
order to accomplish its necessary goal is a way to increase a system's
chances of survival, Mr Wagner. 'Get the most from the least' is not only
bargaining, it is pretty sound biology.
Fifth line of defense: Depression = anger turned inward
Manager: Why do you waste time looking for obscure errors? Don't you
have enough work to
Me: I was changing that paragraph for project xxxx. The error was obvious.
Manager: We do code reviews to catch errors like this. Who reviewed this code?
Me: (knowing correct answer is You Did) I don't know, I didn't check.
Do not minimise your contribution, Mr Wagner... the error was *not*
'obvious', it required *your* Special Eyes and Mind to see, understand,
find experimentally, test for and determine the cost of... all of which
was then submitted for Appropriate Management Approval, as it should be.
You might want to consider a different approach of
'I was working on the code and this just seemed kind of... odd, so I
looked into it while waiting for the compile/test run/lunch break to end.
Sometimes, unpredictably, I'll give one away, for free, it is just part of
my Nature... even though my Gran'pappy warned me about the kid at the
schoolyard who'd say 'Oh, don't worry... the *first* one's *always* for
In short... less attention to Kubler-Ross, Mr Wagner, and more attention
to Newtonian mechanics, basic principles of accounting, a bit of biology
and the simple economics demonstrated by a schoolyard drug-dealer might
give the kind of light which shows the process differently.
- Prev by Date: Re: Here's one problem
- Next by Date: Re: Here's one problem
- Previous by thread: Re: Here's one problem
- Next by thread: Re: Here's one problem