Software-Quality Discussion List
Digest # 007


Tenberry Home
Software-Quality Home
Reducing Defects
Automated QA
Consulting
Site Index

============================================================
           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.