SCOUG-Programming Mailing List Archives

Date:	Sat, 20 Oct 2007 11:27:16 -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 Silver Bullet, Part one

Content Type: text/plain

Once again I had a scheduling conflict which kept me from the
SCOUG monthly meeting. I've had a rash of these recently
which I expect will cease in the near future, even as soon as
next month.

I do feel the loss of Randall Flint who always provided the
touch of the "reality" of software development. He did that
with his Sundial Systems software. He gave us insights to the
microkernel OS/2. He endured IBM's retreat on OS/2 without
whining. He understood. We have missed his presence
recently. Unfortunately we will continue to do so.

I retrieved Michael Jackson's "Software Requirements &
Specifications" from my bookshelf. In retrospect I can't
remember ever reading it though at my age retrospect and
suspect go hand in hand. However, I did find it interesting
that his point that our analysis focuses more on a solution
than on the problem which underlies it.

Sometime back Greg Smith accused me of offering a "silver
bullet", a one thing solves all solution, with the Developer's
Assistant (DA), SL/I, and the Data Directory/Respository
(DD/R). The focus on these "solutions" took priority over the
"problems" which they addressed.

Those problems center about the activity of writing (what
Michael Jackson refers to as description) and the activities
which precede and follow it: thinking, rethinking, rewriting,
synchronizing and testing. The object lies in finding means to
reduce them to a minimum, getting more with less, increasing
productivity.

At the time I introduced the Warpicity Proposal we had two
other major "silver bullets" up for consideration. One, receipt
from IBM the OS/2 source code, proved infeasible due to in
part to legal considerations. The other, ODIN, has proven
infeasible in terms of a "complete", "maintainable", and
"attainable" solution.

Like Michael Jackson I see "description" lying at the core of
things. That description problem, the cost it incurred, IBM
decided cost more than it was worth and abandoned it. Why
any segment of the OS/2 community thought it would
somehow cost them less didn't have the sage observation of
Randall Flint to guide them. The experience of Serenity
Systems since along with lesser projects like Mozilla,
OpenOffice, and GCC, all associated with problems of
description, should lay this silver bullet to rest.

In terms of processing we basically have two forms of
description, that which we input to the process and that
which we get out. If we only get out what we put in, a ratio
of 1:1, we need also to compare the cost in terms of either
time, effort, or money in the preparation of the input to the
same of the process to produce the output. That comes to
N:1.

Thus we have an imbalance that we need to address, an
imbalance of descriptive input to output. While we may not
get to the ideal of 1:1, we can establish it as a goal,
something to approach in the limit. We have the need to
spend less descriptive effort on input.

Now description involves language. In software this involves
both text- and graphical-based languages. We have the need
to minimize both in terms of input descriptions while retaining
the use of both in terms of output from the process. Thus we
have the guidelines which I have often repeated here: "Let
people do what software cannot and software what people
need not". If I have offer a silver bullet, it lies in shifting
descriptive activities and their maintenance from people to
software: have people do less and software more while
keeping the output the same.

Actually that has driven the evolution of software
development/maintenance over the years. We see it in the
succeeding generation of programming languages from actual
or machine language to symbolic assembly plus macros to
third and fourth generation HLLs. We had an executable as a
result using less of an input description. It occurred with the
development of decision tables. It occurred with the
development of flowcharting software succeeded by CASE
(Computer-(Software-) Assisted Software Engineering) to
ease the task of preparing and more importantly maintaining
graphical input.

We have had very expensive but limited tools, e.g. Librarian,
to aid in source code maintenance and synchronization. We
have had similar expensive offerings to "automate" testing.
Each of these offered new descriptive language of their own.

So we have a description problem. With the wholesale
adoption of object-oriented methodology with a much larger
set of descriptive languages in its CASE set (UML) with its
reliance on competitive and incompatible class libraries we
have gone willingly to increasing the problem. We somehow
sense the excess, provide "solutions" like agile and extreme
programming, without tackling the real problem: the imbalance
between the input (people-based) and the output
(software-based) descriptions. OO promised relief in terms of
"reuse", but instead has exacerbated the imbalance.

I have another guideline to offer: "Do necessary things
once;unnecessary, never." This actually ties into the other
previous guideline. It conjures up a starting point of
"oneness": a single description, a single tool, a single.... It
offers something to approach in the limit.

We begin with requirements and specifications. We could use
the same descriptive language as Peter Skye implores us in
the use of "natural" language. Unfortunately natural
language supports something we call "ambiguity" unsupported
in any machine instruction set to date. Thus we have an
"informal" descriptive language with ambiguity for
requirements which we must "remove" in translating to a
"formal" descriptive language for specifications to satisfy the
"needs" of our machines.

Inherently a correspondence must exist between a single
choice within an ambiguous set in the informal description and
that of its formal description. That correspondence somehow
"connects" the two, necessitating that a change in one effects
a change in the other. Thus we have the problem of
synchronization.

Thus we can have a single informal language (requirements),
a single formal one (specifications), and single means of
connecting them (unspecified for the moment). We have
these as starting points.

Now we have the Software Development Process (SDP) with
its five stages of Specification, Analysis, Design, Construction,
and Testing. At input to this process we have "requirements"
into the Specification stage whose output contains the
specifications sans the ambiguity of the input.

Now it makes no difference if our specification language
differs or not with those of the following stages, specifically
the Construction stage, i.e. programming. Software cannot
resolve ambiguity for the simple reason its machine instruction
set can neither recognize or accept it on input. So we much
rely on non-software means, i.e. people. So software cannot
write specifications from requirements possibly containing
ambiguities, only people can.

We could write software that recognized ambiguities and
notified people of such. It might possibly over time offer us an
exhaustive set of choices for each one it recognized. It could
create separate specifications for each one, producing then a
set of corresponding outputs from the SDP. However, if it
found more than one the number of outputs would rise in a
combinatorial manner.

The problem here doesn't lie with the software which can
easily do this in terms of different sets of specifications, but
with their impact on the following stages. Even if the
software assumed responsibility for the remaining stages, the
problem lies with people now having to decide among the
possibly hundreds, thousands, and millions of different
productions as early ambiguities have a multiplicity effect.

In short take amibiguity out early in the specification stage.
Unambiguous input means unambiguous output.

So we know at least one stage, the first one of Specification,
requires people intervention to resolve ambiguities of input
requirements. So we have two connected descriptive writings
involving people. The question remains do we need more?

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

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 [ 20 | October | 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.