SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 22 Apr 2007 12:10:34 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: The Data Repository/Directory/Dictionary (DRDD)--Part 1

Content Type: text/plain

In 1972 I received a regional manager's award for selling and
installing the entire Southern California Region's quota of the
IBM Data Dictionary. Among other things it lead to a
consideration of a $25,000 dollar award to write a "redbook"
about it. My competition for the same award lay in writing a
"redbook" for naming conventions used in programming,
primarily COBOL. It won. I lost.

As all my accounts were DOS/VSE, when the next year IBM
dropped support for DOS/VSE of the Data Dictionary shortly
thereafter all my installed accounts became uninstalled. Hero
one year. Bum the next.

About the same time, again a part of a systemic approach I
had developed, I had equal success with selling and installing
IBM's Data Design Aid (DDA). Again about a year after
installing the product the customers began to discontinue it. I
received calls from the product development group.

"Did the customers enjoy the product?"

"They loved it."

"Then why the cancellation?"

"They designed the data."

I don't want anyone to think I somehow wandered into
Warpstock98 with the Warpicity Proposal without bringing into
it an experience with software development that covered
tens of years (in 1998 actually 42) experience in literally
hundreds of accounts. Aside from serving as a regional
specialist in data communications (CICS) and database
(IMS/DL/I) I served the same role as "improved probramming
technology" (IPT) which IBM introduced in 1970. That included
the chief programmer team, the librarian, and structured
programming. Then later after IBM's SRI (Systems Research
Institute) introduced Larry Constantine and his Structured
Design, which included Structured Analysis as well, I added
that along with my other IPT responsibilities.

So I never sat in some ivory tower separate from the real
world, real people, and real problems just free to come up
with some unreal solution. I didn't invent the backlog problem.
IBM did when it shifted its software development to
object-oriented programming (OOP). Supposedly through the
principle of reuse, class libraries, and a GUI interface using
drag-and-drop we would address the backlog problem. We
would bring software development into the realm of standard
manufacturing, change more into a science than art.

So when IBM began its withdrawal of support for OS/2 and the
third-party applications started their decline a number of
people, an entire community, looked for a way to preserve
the future of OS/2. The culmination of several of those views
became sessions at Warpstock98. My particular session came
as the last one on the last day and immediately after the one
from which ODIN developed.

Now of all the proposals the one that bothered me the most
was the desire to have IBM release the OS/2 source code to
open source. Now without going through all the reasons why
IBM couldn't and wouldn't do this my general feeling was be
careful what you ask for. I would use as an example Serenity
Systems and eCS as someone who has had such an
opportunity.

Basically what I saw then and continue to see now in open
source projects in which OS/2 seems to fail further an further
behind in things like OpenOffice, Mozilla (Seamonkey),
Warpvision, and others translates directly into the "backlog
problem", of having change requests occur faster than we can
implement them.

So if you expect a deciining community with a concomitant
decline in software volunteers with a corresponding decline in
volunteer hours available along with a decline in
organizational efficiency (a harbinger of open source), after
enough declines you look to see what you can do with what
you have left. That becomes your design point for a solution.

Actually I chose a "design" point of a single individual, the last
OS/2 user. That in turn corresponds to one of the stated
goals of open source with respect to individual customization,
of choosing to go your own way.

I chose as a "decision" point the guideline of "let people do
what software cannot and software what people need not."
Obviously (I hope to you as well) involving more software
writing than people writing. It has a corollary. "Do necessary
things once;unecessary, never." The first guideline relates to
what we in IT have done historically to improve our customer
processes and increase their productivity. All I have done is
applied the same analytic techniques used to improve their
processes to do the same for ours.

Thus when some vendor offers software that produces
flowcharts from source code, then people don't have to write
flowcharts, only source code. When another vendor offers
software that produces UML documentation from source code,
then people don't have to write UML documentation (each of
which has its own source code), only source code. That
basically renders that all CASE (Computer Assisted System
Engineering) tools obsolete, which covers the analysis and
design stages of the software developent process (SDP). We
can do all their possible productions from the source code.

Now the switch from third-generation imperative to a
fourth-generation declarative language emphasizes the
previous point in that analysis, design, construction, and
testing occur through software writing, leaving people only to
write source specifications, the one thing that software
cannot do and thus people must.

Thus you do what programmers have always wanted you to
do: get out of the way with all that other stuff and let them
write source code. You produce all that other stuff from the
source code they write. The principal difference lies in their
writing in a specification language for the specification stage
in which the informal language of a change request becomes
the formal language of a specification. That specification
language is the same as the programming language used by
the software.

So you have one language sufficient for use throughout all
five stages of the SDP. You have one set of source code, one
library, one repository. You have one tool, the Developer's
Assistant, which allows editing (creating, deleting, adding, and
changing) of that source, leaving it to the software to provide
all the desired results after that point. One language. One
source. One tool. The "necessary" things.

Now this doesn't occur by magic. If it has responsibility for
source maintenance and processing based on people writing
activity, then the underlying system must support this.
Therein we finally come to the subject matter of this
message: the Data Repository/Directory/Dictionary (DRDD).

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

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 [ 22 | April | 2007 ]

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.