Software-Quality Discussion List
Digest # 008
Tenberry Home
Software-Quality Home
Reducing Defects
Automated QA
Consulting
Site Index
|
|
Software-Quality Discussion List
|
============================================================
Software-Quality Discussion List
S O F T W A R E - Q U A L I T Y D I G E S T
"Cost-Effective Quality Techniques that Work"
============================================================
List Moderator: Supported by:
Terry Colligan Tenberry Software, Inc.
moderator@tenberry.com http://www.tenberry.com
============================================================
March 8, 1998 Digest # 008
============================================================
====IN THIS DIGEST=====
==== MODERATOR'S MESSAGE ====
Formatting
Housekeeping
==== CONTINUING ====
RE: Format of the Software Quality Digest
Rick Pelleg [SMTP:rickp@vdo.co.il]
Formatting
David Bennett
Re:Formatting
John McGrail
Responses to formatting questions
Jim Cook
HTML Example (Part of Digest #001)
Rick Pelleg
Size algorithms
David Bennett
Understandability standards (understandards?)
Jerry Weinberg
On-Line Dictionaries
Rick Pelleg [SMTP:rickp@vdo.co.il]
===== NEW POST(S) =====
Books you could review
Kevin Arthur Mitchell
Learn from thy neighbor -- "Real-estate" for testing
Rick Pelleg [SMTP:rickp@vdo.co.il]
Seeking second career in software quality
luisgutierrez@ibm.net
==== BOOK REVIEW ====
Review of: "Death March"
by Edward Yourdon
==== MODERATOR'S MESSAGE ====
Formatting
We have a number of messages involving formatting, which
is a little off-topic. I have included them because I
want to find a good solution to make this digest as
effective as possible. I found a spiffy new editor that
makes the reformatting really easy, so I will continue
in this format until there is more of a consensus about
HTML. For your formatting information, the lines of
equal signs above are exactly 60 characters, the target
width I am shooting for.
Housekeeping
I have another book review ready, and am including it even
though this digest has grown larger than I like (my target
is 20KB per digest).
We will be doing a little smaller digests coming out more
often in the future.
==== CONTINUING ====
++++ New Post, New Topic ++++
From: Rick Pelleg [SMTP:rickp@vdo.co.il]
Subject: RE: Format of the Software Quality Digest
> >I am working on a small contribution for the discussion.
> >Hope to have it ready soon. In the meantime, I wonder if
> >you can consider a change in the
> >format of plain text with manual line breaks, which I find
> >rather difficult to read.
>
> I will consider it and ask the list. My understanding is that HTML is
> *FAR* from being standard for email. For instance, the Eudora Pro 3.0
> which I use doesn't support it. (There is a new 4.0, which does, but
it
> is rumored to have so many bugs that I haven't dare try it yet.)
I was not thinking of making the email message itself HTML,
but of attaching an HTML file. As to "rich" formatting within
email, I know of at least three methods: HTML, RTF (Microsoft
Rich Text Format) and ETF (Enriched Text Format; I think from
Apple, but don't remember for sure). How we suffer from lack
of standards...
> >I have a
> >small HTML-ing of part of Digest #001 (it was very easy to do using MS
> >FrontPage), and have attached it.
>
> No attachment here, boss!
Sigh... Lack of QA... Do you have an automatic tool to
withhold email's that wrongly say "I have attached..."?
Unfortunately I won't have access over the weekend to the
disk with the HTML file. Will send it on Sunday.
At first look at your pointing out that there is no
attachment I was concerned about something else: there might
actually be another drawback in that there are several
possible encodings for attachments, so one attachment might
not work for all. Of course HTML is plain text, but I don't
think we can expect the Digest audience to manually clip the
HTML from the email and save in a separate file to view.
Perhaps you could check by attaching such a file to the
Digest when you ask about this idea?
> >* You won't have to battle to keep to the fixed number of characters per
> >line. For example, in Digest #006 a couple of too long lines sneaked in;
> >one of them is:
> >"1. The one screen >= one unit of code is a rule of thumb. This is a
> >pretty constant rule because human capabilities"
>
> On the other hand, I *will* have to battle to make the HTML work out.
> The thought of learning another Microsoft tool makes me tired. I had
> downloaded FrontPage, and deleted it after watching it take up space
> on my hard disk for several months.
Perhaps you downloaded the beta version? We bought the
official product "in a box". I found learning plain,
straightforward "slightly rich text with hyperlinks" with
FrontPage was very easy. You do not need the FrontPage
browser at all, just the editor. Before front page I used the
plain old Netscape 3.0 Gold editor, until only a couple of
months ago. It was also very easy to learn to use since it
had significantly less options than FrontPage; however,
FrontPage is definitely a more stable product. I haven't
tried the Netscape 4.0 editor.
>
> The fixed-line editing isn't too hard. What is hard is making
attributions
> look consistent.
>
If you have to work on the attributions anyway, I think it
might as well be on HTML-ing (if my suggestion is accepted).
Regards,
--- Rick
++++ New Post, Same Topic ++++
From: David Bennett
Subject: Formatting
Hi Terry
* 2) Included your name in the From: header of your email.
* (This means you, dmb!)
Sorry...I think I've fixed it but it may not work until the
next time around. Check the sig if you can't remember me!
* >I think HTML is universal enough to use instead of the
* >plain text.
*
* Well, I agree that most folks have a web browser.
* I'm not so sure that they use their browser to get
* email, though. I sure don't!
I agree. I use IE/Netscape for Web, but outlook/Word for
e-mail. It's far more powerful at boiler-plate, spell-check,
macros, fonts, all that other stuff. Until Outlook/Word
supports HTML e-mail easily, I'd rather stick with what we've
got.
Regards
David Bennett
[ POWERflex Corporation Developers of PFXplus ]
[ Tel: +61-3-9888-5833 Fax: +61-3-9888-5451 ]
[ E-mail: sales@pfxcorp.com support@pfxcorp.com ]
[ Web home: www.pfxcorp.com me: dmb@pfxcorp.com ]
++++ New Post, Same Topic ++++
From: John McGrail
Subject: Re:Formatting
Hi Terri,
> Formatting
>
> Rick Pelleg has asked to have the Software-Quality Digest
> distributed in HTML format (see my posting of our email
> for more details.) At the moment, I am trying to limit
> lines to 60 characters, so as to fit the widest range of
> email clients. Would you prefer different formatting?
...
>>* Readers will have their browser font type and size
>>configured according to their personal taste.
...
>>* Use hyperlinks within the digest.
My vote would be for straight text, not HTML, but using
hyperlinks where appropriate (as you already do with the
footers). My mailer doesn't do HTML, but it does understand
links (currently eudora 3).
John
PS. Why I'm interested in Software Quality ...
http://www.channel1.com/users/skaterat/resume.htm
=====---------------------------------------------------=====
John McGrail
American Internet Corporation
http://www.american.com/
mailto:jmcgrail@american.com
1 (781) 276-4568
++++ New Post, Same Topic ++++
From: Jim Cook
Subject: Responses to formatting questions
Terry,
I suggest that emails with automatically wrapped lines be
used rather than an arbitrary number of characters. Most
email clients will size the email text to fit the display
width for the message. At least Eudora, MS outlook, and
Netscape will which are the ones I have experience with.
If you do that, an shorten below 60 characters, the lines all
wrap together rather than full line, short line, full line,
short line etc.
A thought for keeping topics separated. Rather than an email
that is issue #xxx, it might be easier for all to keep track
of the topic and thread if each email was a separate topic
and all simply replied to the topic.
Also, for a quick and dirty threaded message string that is
HTML, you could copy the email sent out into a word document
that grows from the top (most recent stuff first). There is a
good set of free web tools for word on the Microsoft site and
you could simply save the file as HTML and post the newest
version of the file each time. That way, everyone could use a
browser to view content and simply add to the topic with an
email.
There are also some messaging systems (eg caucus) that allow
the creation of topic threads that are responded to and
written with a browser so no compilation or reformatting is
needed.
jimc.
++++ Moderator Comment ++++
The problem I have with variable lines is that I can't
figure out how to do attributions so that they are
readable. I like the "newsgroup" style of prepending a '>'
character, and it just doesn't work with variable-format
lines.
Can you suggest an alternative?
As to organizing the issues by threads, I don't see how to
make that work, since the threads have substantial overlap
in time. How would I know when to send out an issue?
As an experiment, I offer the following post:
++++ New Post, Same Topic ++++
From: Rick Pelleg
Subject: HTML Example (Part of Digest #001)
Terry,
Here is the .
Regards,
--- Rick
Partial SQD #001
...header skipped for now...
IN THIS DIGEST
- MODERATOR'S MESSAGE
- NEW POST(S)
- "Quality in a Complex
Environment" Phil Helms
MODERATOR'S MESSAGE
Welcome to the first issue of the
Software-Quality discussion list digest!
I'm Terry Colligan, your moderator. I have been developing
software (primarily systems software) for over 30 years. I
started this list to provide an environment where developers,
QA engineers and software managers could exchange ideas about
how to deploy very high quality software. I am hoping for a
practical, results-oriented discussion, rather than
theoretical arguments about whether or not you can prove that
the last defect has been found. On the masthead, I wrote,
"Quality Techniques that Work for Us" -- that's
what I hope we can find.
This is my first attempt at moderating a discussion list.
I have modeled this list on John Audette's Internet Sales
Discussion List, which has been the most effective discussion
list I belong to. I welcome comments and suggestions on the
format, goals, policies or any other part of the
Software-Quality discussion list. I will distribute the list
as content is available, so you will gain as much as you put
in. I am moderating to eliminate the job postings and the
"my language/system/etc is better than yours" flame
wars. We will work out more detailed guidelines as time goes
by. To start with, if
- the poster has personal knowledge of the post; and
- the post may help improve software quality, then we'll
use it.
I hope to see book reviews, programming techniques, testing
strategies, design techniques, horror stories, etc. --
anything that might help us deliver better-quality
software.
Welcome!
STARTING QUESTION
Is it possible to economically produce software with such
a low defect rate (< 1 defect per 100K or 1000K lines of
code) that the users see it as defect-free? If not, why
not?
NEW POST(S)
Subject: Quality in a Complex Environment
Software quality in a diverse and complex environment is
much harder to achieve than in a simpler one. A shop with 3GL
and 4GL languages and a RAD tool, and with legacy,
client-server, and Web systems, and looking at data
warehousing, will have its work cut out for it trying to get
everything to work properly and together. Add to this mix the
use of both character cell terminals and Windows PC's, with
both traditional host (DEC VMS) architecture and server (NT)
architecture, plus network communications, geographically
dispersed operational units, and geographically dispersed
personnel, and you have a complicated picture. Some quality
assurance can be achieved by holding certain of the variables
of this mix constant while testing others, and in fact this
is what often happens just by default. This suffices where an
application doesn't touch too many of the components of the
total system, but trying to test out (or just bring to a
state of minimal functionality) something that depends on
more than just a few components can become nothing more than
a guessing game, and not a very efficient one at that.
Suggestions...
++++ Moderator Comment ++++
The above is an experiment. Please tell me what you
saw in your mail reader. (I got semi-formatted text,
but the links worked -- much to my surprise! (Eudora
Pro 3.0.)
Other than counting responses from this experiment,
I call an end to discussions of formatting -- until next
time! ;-)
++++ New Post, New Topic ++++
From: David Bennett
Subject: Size algorithms
* >Terry: I like the suggestion that the correct size is (A) what
* > you can reliably write with no defects, but I think
* > (B) what other people can easily understand is a more
* > important size limit.
I agree, but I'm still waiting for sensible comment on the
other side of the equation. The smaller you make the pieces,
the larger the number of connections. You don't solve the
problem by splitting everything into 5 line functions,
especially if they have names like DoStuff1(), DoStuff2(),
DoStuff3().
For example, take a function with a switch statement
containing 100 entries, perhaps dispatching on transaction
type or implementing a little language. Splitting that into
5 functions, each containing a switch statement with 20
entries gets you nowhere except backwards.
The (A) condition is a good one, but should also say "you can
call from elsewhere without introducing more bugs than if you
had written the code in-line"
The (B) condition is a good one, but should also say "you can
call from elsewhere without making the calling code less
readable than if you had written the code in-line"
It is critically important to judge the impact breaking out
functions has on the caller as well as the natures of the
functions themselves.
When you apply that at the highest level, there should be
functions based on abstractions which capture significant
qualities of the application as a whole, reinforced by the
principle of hiding the actual code in lower levels.
Unfortunately, event-driven systems and component-based
systems generally make that much harder to do than more
traditional monolithic batch-oriented systems, but that's
another topic.
Regards
David Bennett
[ POWERflex Corporation Developers of PFXplus ]
[ Tel: +61-3-9888-5833 Fax: +61-3-9888-5451 ]
[ E-mail: sales@pfxcorp.com support@pfxcorp.com ]
[ Web home: www.pfxcorp.com me: dmb@pfxcorp.com ]
++++ Moderator Comment ++++
It's clear that a 20 line limit will make a large
switch statement less understandable, maintainable,
etc., so any function size standard has to be applied
with a bit of wisdom.
We have mostly short (under 30 line) functions in the
code that we are pleased with, but there are 3 (out
of 3000) functions with over 2000 lines in them. Even
though we have these 3 huge functions, we still believe
that we have a function size limit, and that it helps.
We just don't apply it fanatically.
++++ New Post, Same Topic ++++
Subject: Understandability standards (understandards?)
From: Jerry Weinberg
>Subject: Size modules should be
>
>>Terry: I like the suggestion that the correct size is (A) what
>> you can reliably write with no defects, but I think
>> (B) what other people can easily understand is a more
>> important size limit.
>
>Jerry: I agree, but you can't have A without B, so size A is
>sometimes smaller than size B, but size B is never smaller
>than size A.
>
>Jerry
>++++ Moderator Comment ++++
>
> I strongly disagree. In my experience, there are some
> programmers for whom size A is much larger than other
> less gifted folks' size B. In fact, this was the source
> of lots of problems when the gifted programmer moved
> on -- the 'normal' programmers couldn't understand what
> had been working reliably. Size A may most often be
> smaller than size B, but I have worked with at least
> four programmers whose size A was much larger than
> size B for the rest of the team.
>
> This lead us to commenting standards, coding standards,
> and a size B module-size strategy.
Again, I don't think we disagree, but I can see why I was
misunderstood. I guess I have to be clearer about "what you
can reliably write with no defects" means.
Consider a module (X) that cannot be readily understood by,
say, your testing group. This module has a defect of being
not very testable. Also, not readily modifiable. Defects are
not just in "functions," but also in "attributes."
Without this idea of what a defect is, you fall into the trap
of producing code that, for example, does all the functions
but cannot be changed reliably, or runs 10 times longer than
the users will tolerate, or has awkward user interfaces or
protocols.
Lack of understandability destroys all other attributes.
Still, you have to be wary of using the lowest common
denominator as your measure of understandability, which can
happen if you get too heavily into "commenting standards,
coding standards, and a size B module-size strategy."
I have never yet seen a set of such standards that couldn't
be followed while at the same time producing code that nobody
- including the producer - could understand.
Jerry
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ Moderator Comment ++++
It's an interesting idea -- to put the lack of attributes
that you want into the defect category. I've used it for
testability in our projects.
I worry a bit about defects that are hard to identify
and/or measure, since one of my goals is to push
defect-free software development.
I agree that standards can't insure understandability, but
I can measure the standards I mentioned, while I don't have
measurements for "understandability."
++++ New Post, New Topic ++++
From: Rick Pelleg [SMTP:rickp@vdo.co.il]
Subject: On-Line Dictionaries
Terry,
Following Frank Tonn's cordial provision
of the definition of "grizzled", > griz-zled / adj grey;
grey-haired. (Oxford Advanced > Learners Dictionary of
Current English)
I take the opportunity to share two on-line dictionaries I
find quite useful.
The first is the CPMnet Tech Encyclopedia, for
computer-related words (don't look up "grizzled" there):
http://www.techweb.com/encyclopedia
The second is a gateway that searches several word databases,
thus giving a high probability of hitting the word sense you
need. Its results for "grizzled" are copied below.
http://work.ucsd.edu:5141/cgi-bin/http_webster
Regards,
--- Rick
Hypertext Webster Gateway:
"grizzled"
>From Webster's Revised Unabridged Dictionary
(1913) (web1913)
Grizzled \Griz"zled\, a. Gray; grayish; sprinkled or mixed
with gray; of a mixed white and black.
Grizzled hair flowing in elf locks. --Sir W. Scott.
>From WordNet (r) 1.6 (wn)
grizzled adj : having dark hairs mixed with gray or white
>From Easton's 1897 Bible Dictionary (easton)
Grizzled party-coloured, as goats (Gen. 31:10, 12), horses
(Zech. 6:3, 6).
++++ Moderator Comment ++++
How about if we call a halt to "grizzled"? I'm a
little worried about the direction. (Elf locks is
okay, but I'm not sure about goats! ;-)
===== NEW POST(S) =====
++++ New Post, New Topic ++++
From: Kevin Arthur Mitchell
Subject: Books you could review
I like Code Complete by Steve McConnell.
I've read each part several times and, as a
"newbie" with 0 years experience I find it
approachable yet deep.
++++ Moderator Comment ++++
Thanks, I was looking for something to do! ;-)
Seriously, "Code Complete" has very good word of mouth,
and I even have a copy. It's just *so* thick!
If anyone else would like to write up book reviews,
I'm sure I could be talked into publishing them!
++++ New Post, New Topic ++++
From: Rick Pelleg [SMTP:rickp@vdo.co.il]
Subject: Learn from thy neighbor -- "Real-estate" for testing
The neighbor I am referring to was the VLSI design
department in the National Semiconductor Corp. development
center in Tel-Aviv. My first job after my studies was in the
Software department there. As soon as I was "old" enough to
appreciate it I became envious of their strict standards of
development methodology.
I think that by now there is already a general enough
agreement about the need for software engineering in the
broad sense of the word. Thus I will not dwell upon the old
"excuse": "Hardware" is hard and expensive to change, but
with "Software" -- no problem! Just report the bugs and
we'll fix them. I agree with those who say that "Software"
is a misnomer and that the above is an illusion; in the
final analysis errors in software design and implementation
are very costly, probably the same order of magnitude as
hardware faults.
Now to the point: what I propose learning from the chip-
designers is dedicating a significant area on the chip to
testing functionality only. From a few short phone & email
interviews I held with chip designers I learnt that this
practice is still followed, mainly in general purpose chip
design. Up to 10% of the chip area might be dedicated to
testing. An example given to me was testing circuitry that
allows, as part of the testing, to "toggle" each flip-flop
on the chip, and ATPG-readiness circuitry (ATPG == Automatic
Test Pattern Generation; a VLSI design and manufacturing
verification technique).
The software equivalent is to add testing code to the
product. At National Semiconductor this was practiced even
in embedded software development. Tenberry Software's
approach to automated software is also a good example
(http://www.tenberry.com/autoqa.htm). In the hardware world
chip "real-estate" is expensive. In some areas, such as in
RF (Radio Frequency), it is actually too expensive, and you
will NOT find test-related circuitry on the chips. In
software, however, there is usually no limit to code size
during testing, and the performance penalty of the extra
code can usually be tolerated.
Unfortunately, putting this approach to use is the exception
as far as I have seen in software development. Even before
discussing automated testing, there are the phases of debug
and manual testing. I have frequently seen the developers
themselves "gawking" at the screen because the software was not
behaving as they expected and they had no idea how to start
attacking the problem. It is almost always clear that simple
additional code such as logging to a file would have made
things much easier for them.
Finally, in this context, I would like to recommend the
April 1997 issue of CACM (Volume 40, Number 4), that is
dedicated to "The Debugging Scandal". Among other things
you will find an article by Ron Baecker, Chris DiGiano and
Aaron Marcus, titled "Software Visualization for Debugging"
that suggests an exciting idea for special non-functional
code: use multimedia to follow program execution visually
or audibly.
Regards,
--- Rick Pelleg, rickp@vdo.net
SQA Manager, VDOnet Corp. Ltd.
P.S. A little about myself: I am a real "rookie" compared to
Terry and other contributors: only 12 years in the software
industry. However, it was a late entry, at the age of 29,
after a first career in aviation, and after four years of
B.Sc. studies, both Computer Science and Biology, at the
Hebrew University in Jerusalem.
++++ Moderator Comment ++++
I think that fully automated testing should be in the
requirements for programs. We view it as a bedrock of our
development process, so much so that when I work on an
older system without an automated test suite, I feel like
I'm back in the keypunch-and-two-turnarounds-per-day
times!
++++ New Post, New Topic ++++
From: luisgutierrez@ibm.net
Subject: Seeking second career in software quality
Not sure this message is appropriate for this forum, but
the moderator can delete if it is not.
I just retired from IBM and at 55 I am ready for a second
career in software quality, in the Washington DC area.
Does anyone have any suggestions? If anyone wants to see
my resume, please write directly to me.
Thanks, Luis
Luis T. Gutierrez
Gaithersburg, MD
++++ Moderator Question ++++
Should I include these kinds of postings?
I couldn't decide, but was leaning against...
==== BOOK REVIEW ====
Review of: "Death March"
by Edward Yourdon
Prentice Hall PTR 1997
213 pages
ISBN: 0-13-748310-4
Ed Yourdon's book is subtitled:
"The Complete Software Developer's Guide to Surviving
"Mission Impossible" Project"
Since I had just recently completed a "Death March" project
of my own, I hoped that this was a book I could really
benefit from.
Mr. Yourdon's definition of "Death March" is a project which
has one or more constraints which are wrong by a factor of
two:
- The time allotted is no more than half of what it should
be; and/or
- The staff assigned is no more than half of what it should
be; and/or
- The budget allocated is no more than half of what it
should be; and/or
- The functionality and performance requirements are more
than twice what would be normal.
In short, these projects are more likely to fail than to
succeed. The name Death March comes from the idea that the
only way these projects can succeed is by all-out, extended,
"killing" efforts by those working on them.
The Chapters are:
1. Introduction -- 48 pages
2. Politics -- 24 pages
3. Negotiations -- 26 pages
4. People in Death March Projects -- 32 pages
5. Processes -- 44 pages
6. Tools and technology -- 20 pages
7. Death March as a Way of Life -- 18 pages
There is also a four-page index.
The jacket cover claims that "Edward Yourdon comes to the
rescue" and that he "presents specific, never-before-
published techniques."
My biggest complaint is with the jacket cover -- it promises
a lot more than Mr. Yourdon delivers. Actually, the jacket
cover promises more than any book could deliver! Oh, well,
on to the book:
Mr. Yourdon writes well, and his book is quite readable. You
may find his premise a bit grim, though. He suggests that
more and more projects are Death Marches, and that there is
little you can do to prevent them. There is a lot of
discussion of the symptoms, but not nearly as much about
solutions. Some of the solutions are drastic, i.e. "Quit!"
At many points in the book, I wanted to argue with Mr.
Yourdon's gloomy premises. Unfortunately, I can't -- I think
there is a lot of reality in this book.
The "specific techniques" are more oriented at easing the
pain (or jumping ship), than at solving the problems. Given
the definition of Death March projects, that may well be the
best that can be done.
I also had a feeling that this book is a little fluffy. The
book apparently developed from a series of email
conversations Mr. Yourdon had with various developers. Each
chapter has extensive notes, mostly copies of email messages
to Mr. Yourdon from various experienced development managers.
The notes are 15-25% of each chapter. Some significant
fraction of the text in each chapter comes from editing the
email text, so you see a lot of copy twice.
Mr. Yourdon does an excellent job of organizing the ideas,
and of presenting them, so this is much more than just a
email discussion list digest here.
Don't read this book expecting to find a cure for the common
Death March project. Do read it to raise your consciousness
about Death Marches, so you will at least go in with your
eyes open.
My advice: read "Death March" -- it's well written and
thought provoking. You might want to borrow a friend's copy,
though -- "Death March" doesn't seem like a reference that
you will refer to repeatedly.
=============================================================
The Software-Quality Digest is edited by:
Terry Colligan, Moderator. mailto:moderator@tenberry.com
And published by:
Tenberry Software, Inc. http://www.tenberry.com
Information about this list is at our web site,
maintained by Tenberry Software:
http://www.tenberry.com/softqual
To post a message ==> mailto:software-quality@tenberry.com
To subscribe ==> mailto:software-quality-join@tenberry.com
To unsubscribe ==> mailto:software-quality-leave@tenberry.com
Suggestions and comments ==> mailto:moderator@tenberry.com
============= End of Software-Quality Digest ===============