Re: SIP is not Takt Time

Hi Oli,

>This paragraph helped a lot:

Let us review what I said, focusing on terminology and the way that I use 
it. Bookkeeping must distinguish between number as value (debits) and 
character as expression (credit).

Your link to "Learning Accounting and Bookkeeping Basics: Understanding the 
difference between Credits and Debits." does not tell the story of debits 
versus credit in a way that you will learn to use these categories in 
bookkeeping to successfully record your XP team history.

Reviewing what I said:
> > This is the precise pattern that takes place in bookkeeping.

Pay attention above to my use of the word "pattern." I'm not sure where you 
stand relative to pattern study. But in review, XP is a discipline 
championed by pattern study people such as Kent, Ward, R. Martin, M. 
Fowler, J. Kerievski, to name a few. In present XP practices, however, 
pattern study has been put on a back burner. I will argue that in XP as in 
bookkeeping one uses a universal form of pattern.

The pattern in bookkeeping takes the same pattern form we all know, but it 
differs from software patterns as XP differs from prior software 
practices.  A rigorous  bookkeeping pattern performs a test that is 
required for teamwork accounting. I call this pattern "Cost Accounting." 
Cost accounting differs  from the bookkeeping application found in your 
link to the banking story.

And so, for the sake of getting my research to you, you must forget what 
you presently know about software patterns and about misconceived 
bookkeeping advice, found just about everywhere. Neither of the present 
technologies will serve the accountability needs of your XP Team.

> >The takt values are debits; cycle time is credit.

Terminology is critical. You will recall that my reference to takt values 
is taken from the link that Kent posted:
" from http://www.vmec.org/lean_corner/takttime.html

Kent's link makes this statement: "Cycle time is a measured value, not a 
calculated value as takt time is."

I then argued to you that takt values follow the pattern of debits while 
cycle time follows the pattern of credit. Note that I am saying "the 
pattern of." We are not yet talking about actual debits versus credit. Also 
notice in the quote from Kent's link that its author uses the word "value" 
in the definition of both takt time and the cycle time. Doing so blurs 
number as value versus character as expression, which a bookkeeping 
framework must hold distinct. Numeric value versus character's expression 
is the sheep versus goats of bookkeeping. Before you know this distinction 
you are not doing cost accounting.

Takt time measures value as a "physically real" passage of time. A 
collection of such measurements forms an "intellectual image" of cycle time 
that expresses the sum of the cycles member values at the point in time of 
measurement. I quote "physically real" versus "intellectual image" to focus 
a distinction between the numerical value as a debit versus an intellectual 
expression as a credit. The credit is not a physically real thing; it is an 
image of a thing at a point in time. So we must be careful to not mix a 
character image with a numerical value, or our test for balance will be flawed.

Recall that a bookkeeper is recording a history. Debit's value measures 
"what" item[s] are being recorded; credit's meaning expresses "how" 
accounting forms an image of a whole at a point in time.

When we get to your link to the banking story, we will see that cost 
accounting is at odds with definitions in that story. Their pattern of 
terminology and usages cannot create an accounting of detailed costs, which 
you will want to do when recording a history of your team's contributions 
of work. You are craft people, not capitalists. And so your primary focus 
differs.

> > There is a list of one or
> > more debits for each expression of credit, just as you have a list of
> >  takt values for each expression of a cycle.

Now we study why physically real debits versus an intellectual image as 
credit must be placed in types of categories. Suppose manufacturing 
efficiencies improve takt values. Cycle time simultaneously changes. But in 
bookkeeping, prior cycle times, which are a measure of facts, do not 
change. They remain as they were recorded at their point in time. And so we 
hold in separate categories the measured facts, as debits, versus their 
expressed images, as credit. The two naturally balance because for each 
transaction of debited facts there is a corresponding expression in 
credit's image.

> > The one and only one
> > credit expression is made clear in this example because credit, or
> > cycle, expresses an image of a complete set of measurements.

Credit composes an intellectual image of physically real debits.

>Initially I thought that it should be the other way around, i.e. takts
>would be credits and cycles would be debits.

Let's use this to touch on a point of confusion before we get to the 
banking story. The issue is context. The context of each cycle is made up 
of takt values versus elapsed time. One could draw an image of the whole in 
this way:

                    Elapsed time (credit)
                 /
One Cycle
                 \
                    Contributed takt values (debits)

This graph says that One Cycle, as an entity unto itself, is made up of a 
set of contributed takt values versus a period of elapsed time.

In my experience this takes the pattern form:

                    Solution (credit)
                 /
Context
                 \
                    Forces (debits)

In bookkeeping the pattern form is:

                    Credit
                 /
Entity
                 \
                    Debits

Entity is context. Debits is the forces versus credit as its simultaneous 
solution.

>My reasoning was that if
>cycle times where higher than the goal takt times debits would exceed
>credits, which would be bad.

Your reasoning is sound. If I am interpreting your comment correctly, you 
are bringing in the recursive nature of system structure. This is where the 
pattern form does its real work. In the context of takt values there is a 
cycle of takt values for each unique member takt value that make up the 
set. For example:

                       Elapsed time (credit)
                 /
One Cycle
                 \
                                                    Elapsed time (credit)
                                                 /
                         Contributed takt (debit)
                         (parts of the cycle)    \
                                                    Contributed takt (debit)
                                                 (parts of the parts of the 
cycle)

Suppose "One Cycle," as system entity, has a critical goal. Refinement, to 
achieve that goal, must occur somewhere in a recursive collection of 
contributed takt values. Debit versus credit categories have the capability 
of creating simultaneous views of what if parts versus a whole image, 
because as a part is adjusted, so is its whole compensated.

Access to details is the pattern of bookkeeping I call "Cost Accounting," 
which is designed to offer its user control over detail parts that make up 
an image of the whole.

>However as
>http://www.accounting-and-bookkeeping-tips.com/learning-accounting/accounting-basics-credit.htm
>explains, that's just my bank confusing me.

Keep in mind that this, along with present software pattern study, is what 
I advised you earlier to forget :)

Let's stick with analogy to takt values versus cycle time. Because 
bookkeeping is studying the economics of facts and their controlling 
decisions, credit is expressed in a medium common to all changes in takt 
value. The modern medium of that expression is money. Takt value is 
materials and labor supplied, and cycle time is the sum of $ or # spent.

When you read the banking article carefully you will notice that the author 
is associating the debits with assets and credit with liability. The next 
to the last paragraph carries the statement: "Since liabilities are credit 
accounts..."

In fact there are no "credit accounts" as such. Credit is an operator 
acting upon an expressed accounting. Debit is an element defined in analogy 
to a transforming contract between entity and its contractual debtor.

In short, Oli, the present bookkeeping and accounting practices are not 
prepared to do cost accounting, which is the only level of accounting that 
makes sense in a computerized world.

>  From the above page: "In fact, debits and credits are neither good nor
>bad. Each transaction,whether it be a good transaction (deposits), or a
>bad transaction (bills) has both a debit and an equal credit. That's why
>they call it double-entry accounting."

There is that reason. There is also the journal versus ledger pattern that 
is also a process of double entry. A journal debits facts identified into 
sets, typical of takt values and cycles (1st entry). Journal transactions 
recorded into a listing of data points is cast into an image of accounts 
(2nd entry). Journal's data points report a ledger image. We call the 
process transformation the "balance sheet."

If you study the definition of "Journal" from the glossary in your link it 
offers a clue as to why present technology is falling short of the mark. 
The essence of it is that present day applications skip the journal step 
altogether and post transactions directly to a ledger ( a relational 
database). Consider their definition of journal:

"A journal is the chronological, day-to-day transactions of a company. 
Revenue by sources are recorded in the sales journal and cash receipts 
journal. Expenses by sources are recorded in the accounts payable journal 
and cash disbursements journal. A general journal is used to record period 
ending adjusting journal entries. The Payroll Journal is dedicated to 
payroll entries. The general journal is used for occasional and year-end 
adjusting and correcting entries. The Standard Entries Journal is for 
adjusting entries that occur monthly, such as depreciation and matching FICA."

Your cost accounting savvy bookkeeping framework will have one and only one 
journal. Sales, cash receipts, expenses, accounts payable, (accounts 
receivable), cash disbursements, payroll, standard entry, are all what 
should be called "subsidiary ledgers." They are derived from the one 
journal by filtering transactions according to identified sets. 
Incidentally, the sets overlap, which is a real problem when the journal 
step is skipped.

Filtered transactions carry the essential data points to be cast into each 
subsidiary ledger. (Note that their glossary has no definition of "ledger." 
This is because they have confused subsidiary ledgers with the missing 
journal. The journal is missing because transactions have been posted 
directly to the ledgers. The result is a hairball of overlapping facts 
stored in difficult to access relational databases.)

Cost accounting is not difficult to computerize, but it does require more 
rigor than present efforts have made to date.

>With this in mind, is cycle time a credit because if this measure
>increases, that's an liability increasing?

If what I have said today makes sense, our next communication ought to take 
up the four accounting categories of assets, liability, cash, and capital.

Credit expresses entity's capital as potential in a marketplace. Traded 
potential is converted to actual debits, and an new credit expression is 
set via the facts in the trade. Hopefully a further gain in potential :)

In order to get an image of cash versus capital, I found that one must go 
all the way back to a treatise on bookkeeping written by Pacioli in 1494. 
Later than that, though many likely knew of it, I have found no 
documentation of this orthogonal control that is set in relation to assets 
versus liability. Nonetheless, if you wish to computerize cost accounting, 
I found, all four categories need to be in place as part of a four way test 
for accuracy and completeness. Incidentally, once the on-going test is 
built into the bookkeeping framework, all accounting has the benefit of a 
full time test of all transactions.

>By the same logic, if takt time increases that's an asset increasing in
>value as this goal is easier to meet?

Takt value here is a measure of time. Reducing time increases value.

>What I'm still not clear on is what the transaction is with repect to
>software.

Imagine software being generated in cycles of work, just like any other 
product. Takt values are refined by primarily intellectual input versus 
primarily physical input in a typical manufacturing workshop.

Other than the essence of a primary focus on intellectual contributions 
versus manufacturing's focus on physical contributions, software production 
is no different from any other manufacturing operation.

The first thing you will want to do is to create a list of proposed takt 
cycles needed to complete a software project. They can be loosely defined 
in the beginning because you can expand, contract, add, or split cycles. 
This is precisely how I do it, using different terminology for the same 
pattern, in my building construction work. The pattern, you will recall, is 
universal :)

Dan