Re: is SIP an Emergent Property

Hi Ron,

Your reply is helpful.

>My understanding of the SIP idea includes nothing relating to the 
>"software developer" and everything relating to the "customer".

I hadn't thought of SIP in this way; you have changed my image of future 
communications on this topic.

>The measure is, as I understand it, a measurement / estimate of the amount 
>of time the software spends "being built": the delay between the moment 
>the customer asks for it, and the moment the customer gets it.

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. 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.

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.

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.

 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. Clearly, software is an entity's long 
term strategy that is kin to capital investment. Bookkeeping terminology is 
the language of customers which Kent found weird-assed. Nonetheless, 
bookkeeping is a refined language with a history that makes it difficult to 
improve.

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?

>SIP is an answer to the perennial customer question, "why does it take so 
>long?"

This is the part of your reply that helps the most: communication between 
vendor versus customer. I've spent a lifetime building homes and commercial 
buildings. For me building a building is old hat; for my customer, however, 
the process is a considerable learning experience. It's a perfect setup for 
me to treat my customer as a mark, because my customer doesn't even know 
where or when the cheating is occurring. I don't cheat my customer because 
I have experience being a customer. Vendor versus customer are different 
worlds. Learning to synthesize the two languages is worth our effort.

As an example, building over a hundred buildings I had two legal disputes. 
Both were on commercial buildings. We went to court. In a court case, my 
lawyer is the expert vendor and I am now a blind customer going into a 
unique experience. Turned tables will teach me, as customer, how justice 
works. My lawyer, true to habit, proceeds in his image of my expectation. 
As I learn the process I see in his idea of my expectation, not my 
expectation at all. He is a good man--a skilled counsel. As we proceed I 
learn that if I understood up front how the justice system works in such 
cases he and I would have built a different strategy; one far less 
stressful for both of us.

There wasn't time to accomplish this during the case, but in due time my 
lawyer and I became close friends. I taught him the patterns that occur in 
a bookkeeping framework. Being universal, they fit the issues in a disputed 
legal contract perfectly. The patterns gave us a language of communication 
common to both disciplines.

This, of course, is hardly news among pattern people on this list. Dick 
Gabriel, as conference chair at PLoP'95, pointed out this role played by 
pattern language. His examples crossed the disciplines within software's 
own complex culture. The posts to the SIP list, particularly those from 
Just-In-Time contributors, point even more forcibly to a need for bringing 
in the universal pattern language upon which double entry's template upon 
which bookkeeping's pattern language is built.

But why are software people so deeply vested in reinventing wheels? Long 
term, Kent's display of stubbornness relative to bookkeeping exemplifies an 
issue that is going to make the present generation of software developers 
look foolish, long term. Shouldn't we work to minimize such a detour in 
software's evolution? That seems to me SIP's real mission for bringing 
comfort to life, for both the vendor and the customer.

Dan