SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sat, 3 Jan 2004 18:37:43 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Lynn H. Maxson wrote:
> Peter Skye wrote:
> "Then you are burning a bridge. You are, _arbitrarily_,
> deciding that humans shall no longer need to understand the
> source -- and you are designing a system which will make it
> somewhat impossible for humans to do just that. ..."
>
> Peter,
>
> What am I failing to communicate here? First, I'm writing
> source code and text using literate programming. That says
> that every formal description, i.e. specification, has an
> associated informal, i.e. understandable, description. That's
> what people can do that software cannot.
>
> If IBM were to suddenly drop the source code for OS/2 on you
> with its hundreds of different and separate modules, what is it
> that you could with any degree of rapidity understand?
> Certainly no more than a piece at a time. Then like any
> puzzle you would have to assemble it a piece at a time. Even
> then how much would you understand without iteratively and
> repeatedly rereading the code, possibly drawing pictures on
> the side which you cannot incorporate as comments within the
> code?

Peter's comments about organization still hold. Assume that IBM
gave the complete OS/2 source code to the open source community.
My opinion is that the existing source code would be easier to
grok than what you have described so far. As I understand what
you have described, your equivalent for the OS/2 system would be
something like:

...
VM System, Subssystem y of z, specification a of b.
Scheduler System, Subsystem w of x, specification c of d.
File system, Subsystem u of v, specification e of f.
File System, Subsystem t of v, specification g of h.
Scheduler System, Subsystem s of x, specification i of j.
...
...
File System, Subsystem r of v, specificaion k of l.
VM System, Subsystem q of z, specification m of n.
...
...

At least that is my understanding of what goes into the database
and the order in which we make our entries. Fortunately, once in
the database, we can make things understandable to mere mortals
by ordering our specifications to be readable:

VM System, Subsystem 1 of z, specifications 1 through N.
VM System, Subsystem 2 of z, specifications 1 through M.
...
...
VM System, Subsystem z-1 of z, specifications 1 through Q.
VN System, Sybsystem z of z, specifications 1 through R.
...
...

OK, so the system can be made to produce something understandable
to the uninitiated. But I still do not grok how this unordered
way of doing things helps me as a software "author."

In the past, I have had the misfortune to work with self-
proclaimed "big-picture" people. (I would assume that Peter
has also had the pleasure.) They flit from major topic to
major topic leaving little bits of specks here and there.
(Pun intended.) Their specks of specifications are just
so much dirt to clean up later.

Anyway, when I am serious about coding, I set aside big
chunks of time to devote to one and only one thing: a
specific task at hand. Sometimes that doesn't go over
too well with the boss. At my last job, I wasted a lot
of time in little chunks over a year with a LabView data
system. The first four months of wasted time happened
when my boss gave our student intern a LabView textbook
that was one version out of date for our version of the
software. And the DAC hardware was not from National
Instruments -- the developer of LabView. The textbook
that our intern had only paid lip service to other hardware
vendors, so our intern came to bat with two strikes
against him.

I wasted another nine months back and forth with the
hardware vendor chasing down problems with their sample
code and their hardware specification. Finally, I tossed
the old code and set aside a large block of time for one
thing only: verify the hardware spec for the DAC hardware
and re-code the application from scratch. And that was
ALL that I did for one week--with the boss looking into my
office three or four times a day asking what was going on.

What I left my successor was organized--one week of doing
it right means a lot more than more than a year of bits
and pieces of "big-picture" flitting around.
--
Gregory W. Smith (WD9GAY) gsmith@well.com

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

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
"rollin@scoug.com".

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

Return to [ 03 | January | 2004 ]

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.