SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 15 Jun 2008 12:47:21 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	scougprog <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: About those productivity and cost assertions

Content Type: text/plain

This Sunday's (June 15, 2008) Los Angelel Times contains an obituary on
Paul Thomson, a co-founder in 1968 of the CRFG (California Rare Fruit
Growers). The obituary includes a photograph of Paul which I took
during a tour last year of the South Coast Research Center, an
agricultural facility of the University of Calfiornia. I joined the
Orange County Chapter and the CRFG in 1972 while living in Garden
Grove. I remained a member of the North County San Diego Chapter during
my ten years in Oceanside. I kept my membership for the years I lived
in an apartment in Laguna Niguel. On moving to Simi Valley in 2000 I
joined the Los Angeles Chapter where I have served the intervening years
as its program chair, scheduling seven meetings and five tours a year.

At our home here in Simi Valley on a lot some 80' wide and 100' deep,
some 8,000 square feet, I have approximately 2500 sq. ft. of that
dedicated to a garden and fruited plants. That includes more than 100
fruit trees and somewhere above 200 plants if you include vines,
principally grapes, and bushes, principally blueberries.

I mention this in case you might wonder about where I dedicate most of
my available daylight hours in an activity still designated as a work in
progress. As an urban farmer whose needs to respond to different
seasons and fickleness of nature those have priority over my other
avocations. During 90 degree heat I usually find a shady spot to carry
on other activities like writing messages such as this.

I have asserted that the result of the Warpicity Proposal in terms of
method (specification writing only), software (SL/I), and tool
(Developer's Assistant) will result in a "50 times time reduction and
200 times cost reduction". Asserting something which has never occurred
in the IT profession, whose peak in terms of a single gain probably
occurred with the shift from machine (or actual) language to symbolic
assembly (plus macro). Thus one can understand the difficulty in
credibility, the incredulous reception it has received in certain quarters.

I find myself in something of the same quandry that Richard Hamming
faced when in the mid-60s at an Orange County ACM Meeting he asserted
that in the future all of the programming globally would arise from as
few as 10 "system programmers". Of course, as an engineer, particularly
one preceding the advent of the S/360 and its operating systems along
with the division of labor presented by JCL, what he meant by "system
programmer" differs from the profession which did result. If he had
said "software developers", he would have been closer to the mark.

As one who didn't laugh at his remarks or suggested it stemmed from a
"senior moment" without arguing the truth or falsity of the 10 number,
it comes down to considering just what lowest number given the dynamics
of the client base might apply. It obviously requires an increase in
productivity which hasn't occurred in the intervening years. In fact
with the advent of OO the overall developer productivity has declined.
What hope then exists to reverse this?

Since Hamming made his assertion I have continually in that time
pondered over what must occur to get the IT profession closer to the
goals he had in mind. Thus my quest dates back to the mid-60s and not
to just the months prior to presenting the Warpicity Proposal at
Warpstock 98 in Chicago.

Now I have never understood the objections raised to the "50 times time
reduction" as proposing a shift from manual to machine, the automating
of client processes which has driven the success of the IT profession,
as out of line. It depends on the degree of automation. When you have
a guideline which reads "let people do what software cannot and software
what people need not" then the IT profession should achieve the same
gains for itself as it does for its clients. In point of fact, of
actual client experience, the "50 times" comes off an overly conservative.

If you take into account the implied "personal" associated (or should
be) with the Developer's Assistant (re Personal Assistant), having a
software tool using AI and neural nets with a "familiarity" with the
"history" of the developer, I find it hard to predict an actual upper
limit on the increase in productivity possible.

That just leaves us to consider why a 50 times increase in developer
productivity should have a greater reduction ratio in terms of cost,
some 200 times. We can accept that given a constant per developer hour
cost a 50 times increase in productivity will reduce those costs by some
50 times. That implies that more than specification writing costs occurs.

We have the document which is the program source code. We have the
documents which relate to the operational use of the executables of that
source code. Both types occur in a text, sometimes combined with
graphics, format. We then have two type of reference documents which
refer to the same referents, the data. This suggests that a change in
source code may reflect a need for a corresponding change in other
documents. Thus we have the same synchronization impact of a source
code change in all other source code "assemblies" in which it appears to
which we add those of the text assemblies of the other documents.

Now note that this time spent lies above and beyond that of writing
source code, in our instance of writing specifications. Note that
currently the proper maintenance of these other "text" documents, the
synchronization of the changes required throughout, now rivals and in
most cases exceeds that associated with that of the developer. Enter
the Data Directory/Repository (DD/R).

We have three sets of "raw materials". One for data, i.e. referents,
and two for references, source code and text documents. The two
reference forms are essentially linked in reality and in our proposal in
software used with the DD/R. Thus with any change to a referent or to
its use in source code (statement raw material) we have an automated
means of accessing all assemblies, text or source code, in which it
occurs. We have the same for assemblies of assemblies, ultimately for
programs (sets of programs, i.e. application systems) and for manuals.

Given the reuse of assemblies, supposedly a major advantage of OO
programming, we can change a reference to a referent and have the
software automatically replicate it throughout. If we further consider
it as we do PDF documents currently where we can read them online or
optionally by individual choice print a hard copy, then we no longer
have the long publication lead times or the volume hard copy publication
costs to consider. I would submit that the other 150 times cost
reduction here will also turn out to be conservative.

So when we look today at how we as IT professionals spend our time, to
the staffing required, to the administrative support needed, to the need
for collaboration, to the time for testing, to tackling the change
backlog, to waiting until you get your shot at the system or the
database, to the whole host of activities and the people required above
and beyond the mere writing of specification segments, leaving it up to
the software to organize or reorganize them into optimal wholes, you
will have fewer concerns about "excessive claims".

That's the difference between someone with a systems engineering
background who looks for a seamless fit among all the parts to produce
an integrated whole than a parts engineer like a programmer without
concern about how his piece relates to others. That's their problem.
No. Actually that's "the" problem.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 15 | June | 2008 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.