RE: Re: SIP is "just another Six Sigma measure"?

Hi Oli,

>I'm still convinced you're onto something Dan.

Thanks. I've been refining bookkeeping for 28 years, so if I were not onto 
something there would indeed be cause for alarm :)

>There are some nice clues about debits and credits in your post. I look
>forward to something about books, journals and memos.

I sure wish I had more hands. Since I talked to you last the antiquated 
programming language I wrote my bookkeeping framework in (running in MSDOS) 
got a totally surprising update. The gentleman that now owns the language 
updated it to run as a window in Windows with long file names, fonts, and 
access to full windows memory, as opposed to the two megabytes in extended 
memory DOS. This news has greatly increased my workload as the old code 
could now become a commercially viable product.

>In your paragraph about XP "selecting tests piecemeal" being bottom up, and
>bookkeeping being bottom down: Is that top down as in "My Financial Director
>being happy because we spent 2M GBP last year but invoiced 3M GBP, and
>there's 1M GBP in the bank"?

Imagine top down in the precise pattern that you now do XP. Say I sell a 
house. The simplest thing that can possibly work is to record the sale in a 
single transaction. And so I do so and my books are in order. Then I get a 
story card that requests differentiating the cost of the foundation from 
the cost of the remaining structure. And so I break my single transaction 
into two transactions that carry the same total. I keep working the story 
cards until I have recorded a history of the building's details to the 
satisfaction of all users of the bookkeeping data. Vendor accounts-payable, 
customer accounts-receivable, bank balances, payroll, interest on loans, etc.

In my own bookkeeping framework, since it seeks to support a network 
business model it sets out to break all contracts down to the contribution 
of each individual contributor to the completion of the contract. This 
generates a need for a rigorous distinction between debits, as the value of 
contributions of work, versus credit as an expression of ownership. In the 
contract's life cycle rights to ownership get sold in process, as when an 
employee receives a weekly paycheck, and whoever paid them now gets those 
rights. A well ordered bookkeeping framework, with the benefit of 
computerization can quite easily track this dance of Shiva in real time, 
subject to a complete on-going test for balance between total contributed 
value and total rights to its ownership.

>I.e. down, do you just say: "I know this whole lot balances" and drill on
>down from there?

I have leaned to be suspicious of the word "drill." It indicates that data 
has been moved too quickly into a relational database. The bookkeeping 
journal is recorded in sets as a network of information. When zeroing in on 
historical details within the data store we "filter" sets not "drill" into 
the whole, or should I say into the hole ;)

Therefore where a journal is recorded in sets of data within data, a ledger 
pictures a relation of data at a given point in time. The ledger is a graph 
cast from the data points filtered out of the journal. Corrections are 
never made in a ledger, always in the journal from which a new ledger will 
be cast.

Dan