SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 19 Jan 2006 08:09:24 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Getting there--from purpose to detailed plan

Content Type: text/plain

Sheridan has requested something of a roadmap to assure us
on our journey that we have not lost our way: a detailed plan.
A journey, which has a option of a number of different travel
plans, has to give the reasons for selecting a particular one.
Moreover it must have a specific goal or end-point in mind.

Although I have alluded to it before I have had only one goal
in mind in offering the Warpicity Proposal in 1998 and pursuing
it since: increased productivity.

When IBM began its gradual withdrawal of support for OS/2 its
user community to remain viable would have to compensate
with efforts of its own. In short when IBM's support went to
zero the community would need complete independence of it.
eCS and Serenity Systems have offered a delay, prolonging
the period of withdrawal, but have not provided the
independence ultimately necessary.

That independence means that the OS/2 user community not
only compensate for the lost of IBM support, but also compete
with the support offered elsewhere in other operating
systems like Linux, Windows, and MAC: among the same
competition came the source that forced IBM to decide to
withdraw.

At the time of IBM's initial withdrawal announcement many in
the OS/2 community sought to have IBM release OS/2 source
code to open source. Others sought to basically leave OS/2
alone, given its leadership position, but offer an interface
which would allow Windows applications to run on OS/2. In
that manner address the application deficiency plaguing OS/2.

If you take IBM's OS/2 source code using the same tools that
IBM used, you require the same number of people to do the
same amount of work in the same interval of time. If you do
it in open source with volunteer labor, you need more people
and in all likelihood more time. If you don't have either in
sufficient number or amount, you can't compete.

Thus using the same tools I looked at having the source code
even for free in open source a sure fire recipe for failure. In
truth developing the source code, regardless of what IBM
could or could not release, did not pose a significant problem
given the availability of the APIs. Maintaining it, however, on
a release to release basis did. We would have to effectively
compete in an ability with the same number (or more) of
people to do a specific amount of work in a given period of
time. Thus I saw the challenge as one of productivity, of
doing the same work in the same time with fewer people.

That means improving tools, methods, and processes: a
systemic improvement. A tweak here or a tweak there might
make a better tool, for example, but a 100% improvement in
one activity, e.g. compiling 200,000 source statements in 3
seconds instead of 6, might still leave a 0% improvement
overall.

Individual productivity depends upon how much work you can
perform in a period of time, of how much you have to put in
for what you want out. Productivity means doing the same
amount of work in less time or doing more work in the same
time.

What constitutes work in software development: the writing
and rewriting of source(s): the amount you have to
(manually) write or rewrite to get a given amount of work
out in a given time. Writing or rewriting less seemed a natural
starting point.

As a guide in this I adopted "let people do what software
cannot, and software what people need not." Let people do,
i.e. write, less and software, i.e. tools, do more.

I also have another guide: the least significant number of
times to do something necessary is one or once. I have to
have at least one tool, one method, one process, one
language. The question naturally arises where in any of these
do I "need" more than one. What we "have" to do with our
current tool set differs significantly from what we "need" to
do.

Our journey then consists of examining and changing from an
arbitrary "have" to an absolute "need" with our tools. As a
result the Warpicity Proposal offered one language (SL/I) and
one tool (The Developer's Assistant). In the course of this
journey I expect that it will change from an assertion of mine
whose truth or falsity relies on a known proof process, does it
or does it not increase overall productivity, to one which you
accept as your own.

Thus we have only one goal: increasing individual productivity.
If we choose a language, we do so by picking one which
allows us to achieve the same output with less effort. If we
choose a tool, we do so by picking one which allows us to
achieve the same output with less effort. If we choose a
method,...well, you get the point.

We have to have a starting point in this proof process. We
might has well pick one, a tool, in whose use we cannot
disagree: an editor. Now we need to take whatever we
choose to make it the best possible in terms of productivity:
by allowing us to do what it cannot, and it what we need not.

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

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 [ 19 | January | 2006 ]

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.