Re: is SIP an Emergent Property

On Sunday, January 19, 2003, at 10:39:33 AM, Dan Palanza wrote:

> Viewing SIP as serving a customer's needs, I wonder if time in construction 
> is a wise focus? I don't believe that it is. Shifting my building emphasis 
> to an agile model, bookkeeping's power, I find, is realized by enabling me 
> to demonstrate to my customers dollar value found in quality.

Of course quality is important. No one has said otherwise. SIP is just one
measure, and it is one that happens to focus attention on something of
value to business people.

If two construction companies can do the same job for me at the same
quality, the one with the shortest time to delivery is far preferable to
me, especially if they're working on my bathroom.

> Traditional 
> bookkeeping patterns enable me to measure quality and bring it into balance 
> with other forces in time. I don't know of any other way to do that, and so 
> I welcomed bookkeeping into my own fold, as a builder.

I understand that you do not know of any other way to do that. What has not
appeared here to me, is that bookkeeping is a way of doing it, nor that the
other ways of evaluating the balance are inferior.

I would like to see a presentation showing quality and time to delivery and
other forces, brought into balance through bookkeeping. I suppose this
would look like a spreadsheet or a ledger. But I don't know what it would
look like, because the sole proponent of the idea has not presented the
materials.

The challenge to you, Dan, is to show us a credible project of any kind,
construction or software, with a convincing bookkeeping presentation
balancing the key forces, including quality and time.

> Rushed building construction invariably damages the artifact's long term 
> value. Customers who would rush software production are causing even more 
> damage. Software ought to be a long term expense: kin to brick and mortar, 
> or to machinery. No sane culture rushes into making their long term 
> considerations, and investments.

I believe you are mistaking efficiency for rushing. No one is suggesting
rushing.

A few weeks ago, we had some plumbing problems in our house. We needed a
plumber. When we finally got one to show up, the work required consumed a
few hours and five hundred dollars. However, we waited for a full two weeks
to get the work done. Reduction of a two week project to a few hours is not
"rushing", it is effective scheduling and very valuable to me.

> Software's goldrush proves this point. In the rush a few got rich; good for 
> them. But there is now considerable rubble to be cleaned up in order to 
> restore culture's balance--not the least of which, it seems to me, is a 
> totally confused federal government. Forces are changing and many 
> difficult, long-term problems are coming into view. Understanding long term 
> commercial patterns is sensible up front design: applied common sense, 
> which every contributor shares.

No one here is recommending waste, or forgetting long-term needs in favor
of short ones. We are saying that there are effective ways to do better
work, faster, and less costly. We are saying that SIP is one way of looking
at an overall work process to see where the slippage is.

I recently heard -- was it here -- of a construction demonstration where a
properly-organized project team built a complete house in just a matter of
hours rather than weeks or months. Yet there are houses standing partly
done all around my neighborhood. Is that because there is more quality
going into these houses while no one works on them? I think not.

>  From a bookkeeper's perspective, common sense tells that SIP is not the 
> production problem being implied; it has little to do with work in process, 
> which is an inventory consideration.

It is an analogy, and I, for one, see it as a good one. What makes you
think that it is not a problem? What makes you think that reducing the time
between conception and delivery -- without adversely affecting quality --
would be other than a good thing?

> Clearly, software is an entity's long 
> term strategy that is kin to capital investment.

Sometimes it is. Even when software is a long-term investment, that does
not make waiting without progress a good thing. Earlier delivery of the
same good thing is invariably better than later delivery of that same
thing. I should think that would be easy to demonstrate even with my nearly
non-existent knowledge of bookkeeping.

> Bookkeeping terminology is the language of customers

I must entirely disagree. Bookkeeping terminology is emphatically not the
language of any customers I have ever met, anywhere. Even the finance
people upwards of the payroll department at Chrysler rarely if ever spoke
in bookkeeping terminology.

Perhaps it /would/ be a good language. At the moment, no one I know is
speaking it.

And, with the greatest respect, so far you are not an exception. You speak
/about/ bookkeeping, but you do not present your ideas in bookkeeping.
Again, I challenge you to produce something showing us how to do it rather
than just exhorting us about it.

> which Kent found weird-assed.

I cannot speak for Kent, although sometimes I do feel like his translator.
In this instance, I can speak for myself. I so rarely respond to what you
write, because I cannot connect the things you say to any experience in my
life.

I teach people test-driven design by showing them how to do it, and then by
sitting with them and helping them do it.

Perhaps that would be a good way to teach people about bookkeeping and its
relationship to software development. Or even bookkeeping and how it
balances the forces in construction.

> Nonetheless, bookkeeping is a refined language with a history that makes
> it difficult to improve.

That may be. I am not alone in not knowing the language, not being
motivated to learn the language, and in holding great skepticism about its
ability to improve my life. Nonetheless, owing to an excess of curiosity,
I'm still listening.

> To get software right XP will, in due time, have to implement a body of 
> knowledge intrinsic to bookkeeping. Why not start now? Why not cash in on a 
> huge investment that software people have already made into pattern study?

Because no one is leading the way. Someone is behind us, pushing, but no
one is out in front, saying "Look, do it this way".

XP and agile development got where it is today because Kent and others said
"Watch this".

Your turn to say "Watch this".

Ron Jeffries
www.XProgramming.com
The central "e" in "Jeffries" is silent ... and invisible.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/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/