Software-Quality Discussion List
Digest # 008


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

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

  1. the poster has personal knowledge of the post; and
  2. 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)

From: Phil Helms

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

[Tenberry] * [Software-Quality] * [Zero Defects] * [Automated QA] * [Consulting] * [Site Map]
Last modified 1998.3.9. Your questions, comments, and feedback are welcome.