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

I'm still convinced you're onto something Dan.

There are some nice clues about debits and credits in your post. I look
forward to something about books, journals and memos.

In your paragraph about XP "selecting tests piecemeal" being bottom up, and
bookkeeping being bottom down: Is that top down as in "My Financial Director
being happy because we spent 2M GBP last year but invoiced 3M GBP, and
there's 1M GBP in the bank"?

I.e. down, do you just say: "I know this whole lot balances" and drill on
down from there?

Oli

-----Original Message-----
From: Dan Palanza [mailto:[email protected]]
Sent: 22 January 2003 15:18
To: [email protected]
Cc: [email protected]; [email protected]; Carol Findell
Subject: Re: [SIP] 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
Yahoo! Groups Sponsor
ADVERTISEMENT




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



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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/