============================================================
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
============================================================
February 26, 1998 Digest # 007
============================================================
====IN THIS DIGEST=====
==== MODERATOR'S MESSAGE ====
Housekeeping
Formatting
==== CONTINUING ====
Size modules should be
Jerry Weinberg
RE: Software-Quality Digest # 006
"Frank Tonn"
Re: Software-Quality Digest # 005
Rick Pelleg
The Johanna's
Jerry Weinberg
Specifications/requirements
Jerry Weinberg
Why stopping everything helps quality and productivity
Jim Cook
RE: Software-Quality Digest # 006
David Bennett
===== NEW POST(S) =====
Re: Software-Quality Digest # 006
Matt Balent
WinRunner List
Leslie_Pearson@dtc.org
Format of the Software Quality Digest
Terry Colligan
===== ANNOUNCEMENT(S) =====
Quality Week (QW'98) Program
Software Research
==== MODERATOR'S MESSAGE ====
Housekeeping
First, I would like to apologize for the delay in this
digest. We got a whole bunch of posts on the day
digest #006 went out, and several more the next day.
Since I was busy, I decided to wait for several more
messages, so I wouldn't have to do a digest every night.
(I don't have my tools or act together enough yet.)
Then, four days went by with no posts at all. Oops!
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?
Whatever the formatting, it would be a big help if
your postings:
1) had a subject indicative of their content -- not just
RE: Software-Quality Digest # 000
I started to make up titles (for Jerry Weinburg's posts),
but lost my enthusiasm when all but two of this digest's
postings had the RE: title.
2) Included your name in the From: header of your email.
(This means you, dmb!)
3) If you want to respond to multiple postings, please do
so with a separate for each topic. I am trying to keep
a discussion together, and the formatting is much easier
with separate posts, as Jerry Weinberg did.
4) Until and unless we switch to HTML, this digest is
formatted with 60 char lines with hard line breaks. The
closer you can come to that format, the less editing I
have to do.
I have several book reviews pending, and a number of other
topics to bring up, but I haven't had the time yet...
==== CONTINUING ====
++++ New Post, New Topic ++++
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
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ 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.
++++ New Post, New Topic ++++
From: "Frank Tonn"
Subject: RE: Software-Quality Digest # 006
Hi Terry and all the others
>Any suggestions on *how* to get the structure right?
I totally agree that since breaking a system into
components is critical for the success of a project, the
question is how to find these components.
Although I cannot look at so many years of experience
(see below) here are two suggestions that helped me to
recognize a working architecture or at least feel
comfortable with it.
So far one thing seems to be the most critical about a
software architecture: to meet the requirements. Therefor
I try to formalize the project documents as early in the
development process as possible using design notations.
For example, it seems to be much easier to identify
components in the Analysis&Design phase if the
requirements are written down as UseCases.
The second suggestion may sound rather unconventional,
but give it a try. Pick someone who does not belong to
the project. Try to explain the architecture to him in
one hour using only a whiteboard. If he does not
understand it, the architecture will not work.
I may be totally wrong, so please feel free to comment
my statements.
short bio: I am working as a Consultant/Developer/
Projectmanager/Trainer for a small company (about ten
people, which is one explanation for the four jobs). We
do development of tools and applications, consulting and
training in Smalltalk and Java. I have ten years of
programming experience (four as a professional) in various
environments. I am 31 years old and still not married.
In other words, I'm young (sort of), got full brown hair
and I like well stated criticism. :-)
griz-zled / adj grey; grey-haired. (Oxford Advanced
Learners Dictionary of Current English)
Regards,
Frank
-
Frank Tonn -- Oh night more loving than the rising sun ...
++++ Moderator Comment ++++
I like the idea of explaining the architecture to
someone not related in one hour or less! I'll try
it on our next project.
++++ New Post, New Topic ++++
From: Rick Pelleg
Subject: Re: Software-Quality Digest # 005
> ++++ Moderator Question ++++
>
> Are these kind of announcement postings useful enough to include them?
Yes, please continue.
Regards,
--- Rick Pelleg
++++ New Post, New Topic ++++
Subject: The Johanna's
From: Jerry Weinberg
> This is an interesting article and worth reading,
> but it is by Johanna Rothman, not Schwab.
Whoops! I typed that too fast.
Apparently it was a piece of code that was too long to be
easily understood by the writer.
I was probably thinking of my stockbroker, perhaps hoping
to turn my ideas into some significant cash.
Jerry
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ New Post, New Topic ++++
Subject: Specifications/requirements
From: Jerry Weinberg
>From: "Truesdale, Barbara"
>I've been taught (and, of course, am trying to teach) that
>specifications/requirements are an essential part of the
>quality process - that if you don't have good specifications,
>the quality of the work will be less than desired. I'm
>getting some resistance from both sides of the fence - users
>and developers - because (I think) putting together really
>good requirements is rather hard to do, especially when we
>haven't been taught how to gather requirements until very
>recently.
*Starting* with good specs/reqs is great if you can do it,
but it's biggest impact is on the cost and time to finish.
The most important thing is *ending* with good specs/
requirements. The sooner you get them, the cheaper and
faster it is to finish the building (generally), but
generally there's a certain amount of parallelism in their
development. Even if you start with what you believe is a
good set of requirements, stuff happens. And, the bigger
the project, the more time there is for stuff to happen.
It's an engineering decision to choose the appropriate
amount of refinement in the starting requirements. It's a
decision that involves the cost of waiting, the
probability of change, the capability of the development
crew and the requirements crew, and how close the first
release has to be to somebody's idea of perfection.
Jerry
website = http://www.geraldmweinberg.com
email = hardpretzel@earthlink.net
++++ New Post, New Topic ++++
From: Jim Cook
Subject: Why stopping everything helps quality and productivity
> Any comments on why stopping everything helps your
> quality and productivity?
Terry,
If you build a base code set and add on from there, it is
critical that the base set of code work and stay working.
Defects never get better with age and people may generate
code in that may break when the defect is finally fixed.
In a large project, the impact of changing something (even
a defect) can cause a lot of ripple effects.
The principle is basically:
If the foundation is shaky, continuing to build the house
is risky and expensive.
Also by stopping everything, you get everyone's attention
very quickly. Makes people do a bit of review, checking,
etc. if their work causes the system to break and they
know that they will be the center of attention until it's
fixed. Peer review and attention works wonders.
By doing this daily, you never get more than a day out of
sync. Longer synchronization times just mean more stuff
done that could be wrong when you finally put it all
together.
In actual practice, only a few people who must be
immediately involved with the offending code and
interactions with that code are actually stopped.
Most can keep right on working if what they're doing
doesn't have any linkage to the problem.
Also in practice, it may take a few days to fix a defect.
I've generally reverted to the last good build rather
than leave the defective code in but that's a judgement
call based on the specific circumstances. If the problem
is serious enough to affect everyone, then it's better to
stop them now rather than let them continue to create
code that may be at risk.
Like every other "rule", you have to exercise some
judgement but I try to set "rules" that are based on a
sound principle such that if you have to "break the rule",
it's a signal that you really should examine the decision
to "break the rule". It never hurts to take a few minutes
and ponder the decision to "break the rule". If you do so,
at least you thought about it first and are aware of the
consequences.
The old saw about "we never have time to do it right, but
we always have time to do it over" is apropos here.
Daily build once you reach critical mass in the code has
been a principle I've followed for at least 15 years.
It's one of many elements needed to release something that
works on time (or close).
Jim Cook
++++ Moderator Comment ++++
I thought I disagreed with Jim, but after reading his
explanation, it turns out that we do the same thing.
We just don't call it "stopping everything"! We do
make whoever is responsible stop everything until they
have fixed the problem, but everyone else goes on more
or less unaffected.
We have also found that daily builds are a BIG help.
++++ New Post, Same Topic ++++
From: David Bennett
Subject: RE: Software-Quality Digest # 006
Hi Terry
Some answers - and some questions.
* A technique that we have found to be very powerful for
* maintaining code that you have taken over, but which is
* not commented or documented is:
* Whenever you are reading code, and finally understand
* what it does, write it down-immediately, and as
* comments in the source code.
I agree - we try to do this. Interestingly, the biggest
problem is the source code librarian. It's annoying and
inconvenient to add comments if you first have to check
it out, check it back, updates snapshots, etc, etc on code
you didn't really do any work on.
* I have a couple of questions for David Bennett who posted
* recently. I'm not trying to start an argument; I'm only
* trying to understand the intent of his message. He said his
* company takes quality very seriously. But then he mentioned
* something that seems to conflict with what I've been taught
* in recent courses. He mentioned that they "rarely start
* with good specifications. We create them as we understand
* what is possible, as compared to what is useful, what can
* be documented, and what can be sold." Can I have some
* clarification, please?
Our product POWERflex/PFXplus is a database application
development language. A new feature might be specified as:
Support COM/OLE Automation much the same way Visual Basic
does it.
Add support for new features in Btrieve 7
Add native support for OLE variant data types
Add support for OLEDB/ADO/UDA
It is impossible to write a detailed specification at this
stage. We've never done it before, we have no idea what
the hard bits are, we don't know the tools or underlying
techniques.
We start with research and experimental coding. From this
we build up concepts and some (possibly useful) fragments
of code. Somewhere in there we start a specification, but
it keeps changing as we find out more.
About here we talk about it with our developer community,
but they barely understand what we're on about, let alone
provide useful he build
* works.
Stop everything is tough, but always fix it before you add
to it. Bugs left to the end are bugs you will ship.
* Bad news early!
Always! Did you ever work on a motorcycle? Did you ever
try to take off a crankcase/chain cover, and there are 18
bolts, 17 easy to get at and one hidden behind a stanchion?
Which one should you try first?
Keep up the good work. This is fun!
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 ]
[ Visit our Web Site: www.pfxcorp.com ]
===== NEW POST(S) =====
++++ New Post, New Topic ++++
From: Matt Balent
Subject: Re: Software-Quality Digest # 006
Sorry, no time for lengthy post...
Approaching the 'smaller pieces of code' question from a maintenance
perspective, the worst thing you can do is fail to document your code.
This means both in some form of technical doc and/or developer's notes AS
WELL AS comments in the source. Self documentation should be one aspect
any programmer is evaluated upon.
I've wasted a lot of time with too many defect ridden, esoteric
subroutines/functions written by some self described software 'genius'.
Regular code reviews are well worth the effort too (but, oh well, the end
of the fiscal year is approaching and we need to release this stuff so we
make our numbers!).
Matt Balent
Application Developer
CSC Healthcare
++++ New Post, New Topic ++++
From: Leslie_Pearson@dtc.org
Subject: WinRunner List
Does anyone know of a WinRunner list?
I know there used to be one for the Visual Test testing tool.
++++ Moderator Question ++++
Should I include these kinds of postings?
++++ New Post, New Topic ++++
From: Terry Colligan
Subject: Format of the Software Quality Digest
At 03:42 PM 2/26/98 +0200, Rick Pelleg wrote:
>Hello Terry,
>
>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 dared
to try it yet.)
>The reasons:
>
>* Default font in many email clients is no longer a
>constant width font.
>
>* The fixed number of characters per line is either a
>waste of screen space on today's high-resolution
>displays, or too much per line if you need to
>reduce the viewing window size.
The nicest list digest I get uses fixed-length lines of
60 characters as a compromise to all the different
email clients out there. I have been copying that
digest's format.
>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 have a small HTML-ing of part of Digest #001 (it was
>very easy to do using MS FrontPage), and have attached it.
>I find it much easier to read. Additional
>advantages of HTML:
>
>* Readers will have their browser font type and size
>configured according to their personal taste.
I like this.
>* Use hyperlinks within the digest.
I like this.
>* Better looking on your web archive.
I like this.
>* 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.
The fixed-line editing isn't too hard. What is hard is
making attributions look consistent.
>Regards,
>--- Rick Pelleg, rickp@vdo.net
>SQA Manager, VDOnet Corp. Ltd.
>
>P.S. A little about myself: I am a real "rookie" compared
>to you 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, so I do have
>some general experience.
You seem quite good. I think 12 years is enough to
understand what is important and what might not work...
++++ Moderator Comment/Question ++++
I have posted an email that I sent to Rick, because
I wanted to see what the group had to say about this.
(If I have violated Netiquette by quoting Rick's email,
my apologies to Rick.)
What do you think? Would you rather have HTML?
(It's probably more work for me in the short run, but
I will get the right tools to make this work...)
===== ANNOUNCEMENT(S) =====
From: Software Research
Subject: Quality Week (QW'98) Program
Keywords: Quality Week (QW'98) Program, San Francisco, 26-29 May 1998
THEME: Countdown to 2000
KEYNOTE SPEAKERS:
Cem Kaner, "Year 2000, How Can I Sue Thee? Oh, Let Me Count the Ways"
Dave Parnas, "Software Engineering: An Unconsummated Marriage"
Robert L. Glass, "The Software Crisis - Is it for Real?"
Boris Beizer, "Prioritizing Y2K Testing: Debunking Special Date Myths"
Robert V. Binder, "Testing Object-Oriented Systems: Best Practices"
Dave Duchesneau, "Design for Test: Make it Hard for Bugs to Hide"
TUTORIAL SPEAKERS:
Boris Beizer, "An Overview of Testing -- Unit, Integration, System"
Martin Pol, "Test Process Improvement"
John D. Musa, "More Reliable, Faster, Cheaper Testing"
Tom Gilb, "Evolutionary Delivery Project Management"
Hans-Ludwig Hausen, "Software Metrics for Procedures, Objects and Agents"
Robert V. Binder, "Testing Strategies for Object-Oriented Systems"
Ed Kit, "Automating Software Testing and Reviews"
Michael R. Lyu, "Current Techniques and Tools for Software Reliability"
Michael Deck, "How Testers Can Use Formal Methods"
Linda Rosenberg & Mr. Larry Hyatt, "Metrics for QA, Risk Assessment"
PLUS: Over 60 regular papers in 5 tracks for 3 days; Birds Of Feather
Sessions organized by Danny Faught & Brian Marick, Panel, ~30 Exhibitors.
+-----------------------------------+-------------------------------------+
| Quality Week'98 (QW'98) | Phone: [+1] (415) 957-1441 |
| Attn: Ms. Rita Bral | Toll Free: 1-800-942-SOFT |
| SR/Institute, Inc. | FAX: [+1] (415) 957-0730 |
| 625 Third Street | E-Mail: qw@soft.com |
| San Francisco, CA 94107-1997 USA | |
+-----------------------------------+-------------------------------------+
P.S. Please accept our applogies if you receive this message multiple times.
=============================================================
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 ===============
[Tenberry]
* [Software-Quality]
* [Zero Defects]
* [Automated QA]
* [Consulting]
* [Site Map]
Last modified 1998.2.26.
Your questions,
comments, and feedback
are welcome.
Tenberry Home