Re: Re: SIP is not Takt Time

On Tuesday, February 11, 2003, at 2:18:43 AM, Dan Palanza wrote:

>>Here is where I feel us separating. If SIP is time from feature defined to
>>feature in hands of user, then in fact short SIP will tell us a lot about
>>whether it's the right software: the user will say "No, wrong, not it".
>>That's why the Customer Team in XP is supposed to include real users.

> Bookkeeping has a built in test. That test is there to serve both the craft 
> contributor writing the software and the business person as a customer 
> buying a service. The customer needs the bookkeeping test just as much as 
> anyone in the chain of commercial trades that is taking place.

Anterior retrograde economic theory (ARET) addresses the same issues as
bookkeeping, but its tests are both simpler and more clear than those of
bookkeeping, which is burdened by its hundreds of years of history without
improvement in theory or practice. Everyone needs ARET tests, which
completely supercede the notions of bookkeeping.

> This is where Kent's comments change things. Kent said: "Eventually I'd 
> like to make SIP money-oriented--the time from when the money starts 
> flowing out to the time when the money starts flowing in (really hits our 
> bank account)."

> Clearly Kent want bookkeeping. Kent doesn't seem to know yet that his 
> stated goal is what bookkeeping is and has been for 600 years. Surely you 
> see that Kent's concern for where the money is--a most natural concern--is 
> every bit the concern that a customer suffers investing money in producing 
> software.

I scent the pony again. Kent wants SIP to be money oriented. /You/ want
that to be done by bookkeeping. Many of us are more or less money-oriented,
yet essentially free of bookkeeping. Bookkeeping may or may not be a
solution to Kent's problem. I'd like to know.

>> > Something more is
>> > needed. My argument is that there is an issue of a greater whole that is
>> > complementary to and an essential part of the XP and SIP facts.
>>
>>I'm not sure what greater whole you are mentioning. Feature idea to feature
>>in hands of end user is pretty wide. What else are you trying to encompass?

> The same issue that Kent has added to the context of our conversation when 
> he said: "This brings the length of billing cycle and the length of the 
> collection cycle into the picture".

> Whether software contributors are aware of it or not, the money cycles that 
> Kent is calling to mind are always happening. There is no reason that 
> knowledge of these money cycles cannot be fully present in the day to day 
> decision process that takes place between the software's craft contributor 
> and the software's customer.

Yes, I'm sure we all agree with that.

> If your experience then is like mine, you will find that more often than 
> not such knowledge will expose instances where too little money is being 
> budged in one place and too much is being spent in another.

Yes, I'm sure we would find that.

> The bookkeeping pattern, you will learn, is identical to the issue of
> documentation.

Identical? Are you sure it's identical? I know a lot about documentation.
Does that mean that I know a lot about bookkeeping?

> You 
> have told us that there is a right amount of documentation. And the craft 
> person in the heat action, in many cases, is the best person to decide what 
> should be documented.

Oh ... I guess you meant "analogous", not "identical" ...

> The same pattern works for economics. If a contributor does not know where 
> the requirements stand relative to a budgeted whole, some things are going 
> to be rushed when they deserve more time, and other things are going to get 
> wasted cycles because someone harbors a myth that there is value in a thing 
> when in fact there is not. Knowledge is power.

Actually, probably not. Knowledge and power are, in my experience, almost
independent variables.

>> > A sound
>> > bookkeeping framework creates a real time whole image of a project in 
>> which
>> > the story cards are elements of a language that in due time tell this
>> > greater story. The stories that are not yet in process are represented by
>> > estimates. There are many examples of this both from building and
>> > manufacturing that I could share.
>>
>>You have driven into the weeds here by adding in your favorite pony, or
>>some metaphor that works. Bookkeeping is a way, not a truth. What is the
>>additional information about a software project that you'd like to track,
>>outside of SIP?

> I wracked my brain on at work wondering how I might reply to this. When I 
> got home Kent had done the job for me by saying: "When I was at a 
> supercomputer startup, everybody was aware the number of days receivables 
> stayed outstanding, partly because of the cash flow implications (would our 
> paychecks clear), but mostly because it was the most concrete feedback 
> engineering got about whether we were doing a good job. If receivables went 
> from 45 to 90 days, it was most often because we weren't delivering 
> value--customers didn't have enough training to use the machine, the 
> installation procedure was too hard, the hardware was flaky."

But Dan. The people in question didn't know bookkeeping. They didn't use
bookkeeping. They knew the number of days receivables stayed outstanding,
and why.

> Bookkeeping, Ron, is more than just a way. Like all good tests it does 
> deliver a truth. Once you understand the bookkeeping test, in all its 
> simplicity, which gives it its power to know present states in the money 
> cycles, you will feel differently toward what you are saying above. There 
> is ignorance here to be transformed into knowledge.

I am so sure of that. I keep hoping that you'll quit selling the
bookkeeping product and deliver a demo copy.

>> From the intelligible part of the above quoted para, I guess you are saying
>>that the stories actually undertaken and their fate in the hands of users,
>>as optimized according to SIP, are part of the story. Another part is the
>>stories "contemplated": written on cards but not yet committed into detail.

> Chinese philosophy places stories into two categories. One category is 
> "yin," which translates as "the cloudy, or mysterious." Yin is day to day 
> story cards that, once knitted together, produce a working system. Stories 
> knitted together form the category the Chinese call "Yang." Yang translates 
> as "something shone upon, as banners waving in the sun."

> How individual software stories tie together to form a concise and seamless 
> whole is a mystery for me, just as how bookkeeping stories may be a mystery 
> for you. But once tied into the whole, we tend to take for granted how the 
> magic came into being. Well, the reverse happens as well. For the customer 
> requesting stories and the craft contributor programming them into a coded 
> fabric, it is just as easy to take for granted that somehow the details 
> will all fit together into the right seamless whole, the magic that we are 
> looking for. In the yang category of stories of the system as a whole 
> software has as large a graveyard--or Balls of Mud--as any other discipline.

The preceding two paragraphs exceeded the capacity of my metaphor buffer.

>>A product vision in story cards; a movie vision in storyboard, with scenes
>>not yet shot and perhaps never to be; architectural sketches of home
>>features or room treatments perhaps never to be built: these seem to me to
>>be analogous.

> Precisely, and in bookkeeping this is called a "budget." Some of the budget 
> will be over spent, and some will be under-spent. A budget that is 15% 
> disbursed and 20% off of the estimates, is a powerful indicator of where 
> the final costs will land. In my own experience, once computer feedback 
> made budgeting worth the effort, accuracies within 1 or 2% became 
> commonplace. If working professionals are doing the ball-park estimates, 
> and no one is stealing the money when costs run under budget (a common 
> practice) balancing yin versus yang is quite simple to accomplish.

I am really sure that a product vision is not a budget. I am really sure
that a movie storyboard is not a budget. I am really sure that a sketch of
a new building is not a budget for its production. A budget is a low-level
list of items and costs, probably in time and dollars, perhaps laid against
the calendar or perhaps just as a list. The budget is a particular detailed
view, not of the movie, but of the potential making of the movie. I
wouldn't go to the theater to see a budget.

>>Yet there may be an important difference as well. It is possible, some of
>>us claim, to produce software effectively and well by taking the most
>>important story and shipping it.

> Correct. This is the meat and bones of what electronic computing has made 
> possible.

>>No one claims that for a movie or a house.

> I bet such claims are made for a soap opera:) Relative to houses, I can 
> tell you that bringing the customer into the design of iterative 
> construction cycles is much easier than you might be imagining.

Are you suggesting that you can come over to my house, install one cabinet
in my kitchen, and smoothly transition me to a complete, well-organized,
beautiful kitchen? I /am/ suggesting that we can do the equivalent in
software.

>>It may be that bookkeeping will one day help us address the comparison of
>>those things. Today, to me, bookkeeping is just a word with an odd
>>complement of o's and k's and e's. You keep inviting us in, but your home
>>has no path from the street, and no visible door. Until those are built, I
>>can't stop over to your place. Yet I still seem to be able to think about
>>these ideas somewhat effectively. Maybe we should continue to deal with the
>>ideas and let the bookkeeping happen when it's ready?

> Sort of how previous generations of software developers did documentation, 
> Ron? Bookkeeping will come into software by using the iterative model, just 
> as XP has come into software using that model. You are doing bookkeeping 
> now, but very badly. Just as software was been documented in the past, but 
> very badly. No software problem is going to be solved with a sweep of the 
> hand. When XP professionals turn to bookkeeping, they will do so in the 
> same way that the electronic computational model has always been 
> implemented, on a piecemeal basis.

Implement one ******* bookkeeping story for me, Dan. Just one. Please quit
selling and start installing.

Ron Jeffries
www.XProgramming.com
Do only what is necessary. Keep only what you need.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/