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

Hi Dossy,

>On 2003.02.01, Dan Palanza <[email protected]> wrote:
> >
> > 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.
>
>How can you apply this refinement of record keeping detail to software
>development?
>
>How much record keeping is "just enough" to compute SIP?

Kent's version of "SIP" may include something I don't yet completely 
understand. That possibility aside, I would treat software development the 
same way I treat borrowed money. A business entity borrows money to enable 
goals that would not be possible without that block of cash. An entity 
keeps its money in a pool, or reservoir, using it where and when it will do 
the most good. Software, I would propose, is a knowledge reservoir. Whether 
to add resources to that reservoir depends upon the potential for increased 
return on the investment.

Once a software pool is established, say as a contract to supply software 
services to a business entity that has a proposed return on investment, 
this pool can be treated the same that any other lean manufactured product 
line is treated. Here the pattern is as I proposed it in today's email to 
Kent. One breaks software's contract into cycles as team's propose 
expenditure focus that would reap the greatest return.

The amount of recordkeeping would be decided in the same way it is decided 
for manufacturing expenditure. But instead of takt value as a measure of 
physical contributions of work, for software takt value is a measure of 
intellectual refinement of entity's control language, which has a definite 
once and only once aspect, as its long term goal. Software, as is money, is 
an issue of policy decided by equity considerations: how much investment 
will enrich entity as a whole. Equity differs from Profit [loss] as long 
term considerations differ from short term considerations. Software ought 
to be most often long term.

Dan