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

Hi Dossy,

>In my experience, business needs don't stay the same for long enough
>where a "universal application" can be cost-justified.  They tend to be
>orders of magnitude more costly than the "unique application" which is
>custom-fit to solve the specific known problems of today without too
>much anticipation of future problems which we may or may not need to
>solve.

Nice. I will argue that in bookkeeping those orders of magnitude can be 
reached through iterative process typical of XP. Where XP is bottom up in 
the sense of generating unique coded solutions, bookkeeping supplies a 
design toward universal architecture. Bookkeeping, like XP, works best when 
constructed by iterative process; one need only implement what is essential.

Unique versus universal has its cost consideration in double entry 
bookkeeping as well. In bookkeeping a debit system defines behavior unique 
to individual contributors. A simple bookkeeping is a pocket full of cash 
from which one pays each worker directly. Balance is expressed, as revenue 
is added, by how much cash is in the pocket.

Credit differs from debits; as debits measure unique contributions, credit 
expresses a universal potential as working capital. Credit comes into play 
when an owner assigns debit value into a universal accounting, where value 
of different types can be identified. Without universal credit accounts 
there is no bookkeeping true. An analogy would be to program with out code. 
Debit versus credit is unique cash value versus universal capital expression

Does unique versus universal occur in pattern form XP? IOW, where 
bookkeeping begins with universal accounts to order the value of unique 
contributions of work, does XP begin with something unique, such as the 
application code versus something universal? I believe it does, and I also 
believe that a professional approach in each discipline will want to refine 
both the unique and the universal consideration.

In XP work begins with a work order, as story card. The programmer makes an 
assessment of a sensible, simple starting point. Before writing code the 
programmer adopts a rule in the form of a test, as control (keep in mind 
that in bookkeeping accounts are control tests). "Code must behave 
according to this test's rule."  The test in XP, I will argue, is a 
beginning point of universal considerations of XP. As you build story upon 
story you will refactor your test strategy to enable fewer rules of test to 
generate increasingly complex roles played by the code. The pattern in 
bookkeeping reveals that where roles are factored toward allowing 
complexity, rules are refactored toward a refined simplicity.

There may be any number of ways to write code that completes a story card, 
but the XP programmer is arguing that all of the many ways that might have 
been created will follow a set of rules that are fewer than the possible 
behavior patterns code can generate. And so by focusing on universal rules, 
as tests, stronger and more flexible. code patterns can be created when 
subject to tests.

>Implementing features to solve problems of tomorrow is like keeping
>inventory.  Keeping excessive inventory is waste -- thus, if we can
>position ourselves to develop software in a just-in-time fashion,
>minimizing the amount of "feature inventory" we keep ... we can react
>quicker to our business needs while keeping costs at a minimum.

In principle, your argument makes sense. I would counter that XP, which 
separates code versus test, is taking advantage of a natural relation 
between unique behavior as code versus universal identification in tests 
whose rules successfully control code behavior. The test is a control 
device. I argue that in selecting tests piecemeal, XP is primarily focusing 
on bottom up design. Code can be written to do anything--the danger of 
excess inventory of which you speak--which brought XP into being in the 
first place.

In due time I hope to show that bookkeeping offers much more natural ways 
of measuring the excesses of which you speak. But to get to that day in 
time, I need to first convince you that bookkeeping is worth the up front 
effort needed to understand its pattern. To do that I will argue that 
bookkeeping differs from XP only that its iterative process works top down 
versus XP's iterative process that works bottom up.

>Since we can't change what we can't measure, we measure things like SIP
>to give us an idea of our software-work-in-progress.  This will, at some
>future date, convert into "software feature inventory".  Inventory that
>we cannot "sell" or features we don't use, is waste.

Again, your argument is clear and correct. What is less clear is the rule 
by which SIP will be meaningfully measured within the entity as a whole: 
the effect on capital's potential.

>Again, this is why minimizing SIP /time/ isn't necessarily good.
>Sometimes, we might want to look at minimizing SIP /quantity/ instead or
>as well as SIP time.

What is the difference between /time/ and /quantity/? In this context 
quantity seems to me to be an amount of time. Aren't we looking for a 
/value/ of time so that we can compare software costs with other choices we 
might make in spending capital ?

>Even if our SIP time is really low (we push
>features out the door fast), if those finished goods can't be moved out
>of inventory (actually used and value received from the business
>customer) then we're just stockpiling inventory at a fast rate.

It seems to me that what, if anything, is being inventoried is the value 
paid out to programmers for time contributed. In bookkeeping this is called 
an "expense." The bookkeeping rule is to measure expense against some form 
of revenue. Say that 4% of total revenue is devoted to information 
technology (IT). If IT expenses exceed that figure then an alarm sounds. 
One might look for ways to justify an overage because the extra work 
generated increased profit, or whatever.

In economic metrics, if not all metrics, there is always a "versus" issue: 
expense versus revenue.

>Perhaps a complimentary measure to SIP would be a finished-goods
>inventory measure vs. orders shipped -- how many features are
>implemented that are actively used by users vs. are in the product but
>aren't being used.  When the latter increases faster than the former, it
>should raise some flags ...

I believe you would do well to abandon a manufacturing model for software's 
metaphor and adopt the pattern model in its place. Software, like 
bookkeeping, is a professional service. An issue in common with 
manufacturing, when using the pattern metaphor is capital.

Capital, in bookkeeping, is an expression of a business entity's potential, 
typical of heat energy in an electrodynamic system. Money is often thought 
of as synonymous with capital both because it is a reusable resource, and 
its presence gets work done. The expressed value of software is most like 
money, with maintenance cost in analogy to interest cost. Software, like 
money, is reusable, and at far less cost than money, particularly once code 
is in place.

This takes us back to the unique versus universal argument. If you owned 
the company, likely you would want to see code continually refactored 
toward a universal set of rules, as tests for accuracy and completeness 
that could serve the company's complete IT needs. Now I know this is a 
tough problem considering compilers, databases, legacy code, etc. But 
aren't all things to be considered by a company in addition to XP's SIP? 
Wouldn't a top down model, typical of bookkeeping, get the future savvy 
business person in this position? I see bookkeeping as XP's best friend.

My argument to you is, that if you had a good bookkeeping framework to work 
with, you would not only be working bottom up toward that goal in XP, you 
would be working top down by using the bookkeeping pattern. Why reinvent 
it, as SIP attempts to do? You might see a day when you would ask yourself 
why you would ever give anything so valuable as the code you create away 
for a pittance of what it is truly worth. Do you see the Bush Family White 
House giving money away for a pittance? No, they are taking money back out 
of the treasury wholesale to give it back to the rich for recycling.

Do you believe for a minute that people motivated by money will care 
whether software people are gainfully employed or starving, in the future? 
I don't want to create panic, but perhaps if software people learn to 
reason the way rich people reason it would be good for the world, so far as 
creating a natural harmonic balance between unique bottom up creativity 
versus universal top down control.

Dan