Letters

If the norm were to test exhaustively, then, arguably, it would demand little more than an aptitude for detailed work and a tolerance of tedium. Exhaustive testing, however, is not even remotely feasible, so effective testing demands the ability to devise and execute effective tests, and certain skills necessary for this are also necessary skills for effective development. Specifically, I am thinking of the abstract reasoning skills to see, at a systems level, where the probability or cost of an error is high, and the creativity to design tests that determine whether or not that error has been made.

A developer who is unable to take this approach to his or her work will deliver bug-ridden code. It is important to realize that this is not just a matter of debugging one’s own code; it is about not making (too many) mistakes in the first place, by anticipating where they might occur, and of designing effective solutions that are not prone to problems in the first place.

Poor code that has been patched, whether before or after being deemed completed by its developer, is not as good as code that was good from the start, and will continue to be a problem for the rest of its life. (For one thing, one of the better predictors of the number of bugs remaining in a system is the number already found.) To take people from where they are preventing bugs to where they are finding them after the fact is a retrograde step contrary to the spirit of Larry's thesis.

The proper way to "left-shift" their skills is to provide a career path for effective programmers into design; every true engineering discipline is structured this way. That is not to say that QA shouldn't be involved in design, but at every stage of the development process and at every level of abstraction, quality is achieved by a combination of proactive and reactive measures, with the former being preferable, if you have that choice.

Andrew Raybould
andy.raybould@worldnet.att.net

Larry responds: Andrew, I believe you have completely missed the main thrust of my article. You persist in seeing QA as an afterthought — "To take people from where they are preventing bugs to where they are finding them after the fact is a retrograde step." That is precisely the opposite of what I contend is the much better way.

QA is not a bug-fixing pass, nor should it try to bring help to bear to "finding" bugs, it truly is your resource to prevent them. It is (or should be) a process, one that must begin at the beginning, before a single line of code is written. People with the systems-oriented approach you describe — working from a QA mindset, with the resources of the QA department to draw on — can do exactly what you described them doing for development. But they can do it faster, easier, and better. Quality cannot be painted onto software as a final step, it must be engineered in. I'm afraid you illustrate precisely the problems that exist in the current perception of Quality Assurance.

Andrew responds: Larry, since writing my original reply, it has occurred to me that there are other ways of explaining my point of view, and additional conclusions that could be made.

My original letter argued that the idea of moving developers who are good at testing into QA is contrary to your stated goal of detecting bugs as soon as possible. The argument goes as follows:

1. All good developers will be good bug-finders, because the skills to be the latter are also essential skills in being the former, as I explained in my initial letter.

2. From 1, if you argue that developers who are good bug-finders should move into QA, then you are arguing that all good developers should move into QA.

3. A corollary of 2 is that only poor developers should remain in development! This, together with 2 itself, is consistent with the view that "it doesn't matter how well the development work is done, we will fix it in QA," and that, in turn, is contrary to your main thesis. Furthermore, there is not much point in left-shifting QA into design if the coders are going to mess up the results.

4. If you argue that coders who are good at finding bugs will be more effective working at design-level QA, then I will counter by arguing that they will be even more effective working as design-level developers, because they can prevent errors from appearing at this level (bugs are created by developers, so only developers can avoid making them). This line of reasoning remains true no matter how often and how thinly you slice the levels of abstraction: As I explained in my previous reply, the presence of QA at some level implies a development presence immediately before it, else what is QA evaluating? (You gave an example in which you were involved in assuring, at the design level, that logging would be adequate for testing. This is a case where you caught the failure of the designers to produce a testable design.)

5. Conversely, if you argue that being a good coder is no indication of how well someone can develop at a design level of abstraction, then I will counter that there is no reason to believe that they can QA at that level of abstraction, either, and if they can't do one, there's reason to believe that they can't do the other — the problem is with the level of abstraction, which is the same in both cases.

6. If you claim that a good developer working at some level of abstraction would stop more bugs by doing QA at that level, then, even if this were true (which I doubt), it is tantamount to abandoning trying to prevent bugs at that level, in favor of catching them. This is contrary to what you espouse in your reply, and it will not lead to high-quality software, as I explained in my original letter (once a lemon, always a lemon).

There are a couple of ways that you might try to get around this line of argument:

1. QA should be involved even before development is, which would get around step 4 (for this specific case, only). This implies, however, that QA should be involved while the problem definition is still in the user domain, before we have begun to translate to the computing domain (once that happens, development is involved). I have no argument with that, but it does not make sense to move developers, no matter how good at bug-finding they are, to this level of QA, because their knowledge is presumably in the development, rather than the user, domain.

2. My argument doesn't apply to developers who are good at finding bugs but, for whatever reason, are unsuited to do development work. I agree that this set of developers-who-are-good-bug-finders would be more effective in QA. Your original suggestion, however, did not make this distinction.

You could also claim that would-be design-level developers should first spend some time working at design-level QA, and you would get no disagreement from me.

Curley Brackets

Dear DDJ,

I enjoyed Jared Jackson's "Java Q&A" article, "What Are Resource Bundles and What Do They Have To Do With Internationalization," (DDJ, September 2001). However, please note that what Jared refers to as "curly brackets" ("{" and "}") are properly called "braces."

Steve Walton
swalton@tribune.com

Jared responds: Steve, I'm glad that you read and enjoyed my article. I am even more pleased that the greatest error you could find is in my possible misrepresentation of the name of some punctuation. I went to dictionary.com to try to clear this matter up and found the following definition under "braces":

14. Mathematics. Either of a pair of symbols, { }, used to indicate aggregation or to clarify the grouping of quantities when parentheses and square brackets have already been used. Also called bracket.

Perhaps braces would have been more appropriate, though I don't think I've lead too many programming souls astray. By the way, the greater error in the article is the capitalization of the "P" in the word "public" in one of the code listings, which will make that listing uncompilable without the minor change.

Trampolines for Embedded Systems

Dear DDJ,

I read the recent article by Joseph Link, "Trampolines for Embedded Systems" (DDJ, September 2001) with considerable interest. I thought that your readers might be interested to know that the Asynchronous System Trap (AST), which he describes, has been used successfully in an RTOS for over 12 years and in hundreds of embedded systems.

The RTOS is my company's SMX, and we call the object a "link service routine" (lsr). Operation is a bit different, but the basic principles are the same. I thought that I had invented this concept in 1989, but as Joseph correctly points out, it first originated at DEC (although I believe that the concept was first used in the pdp11, not the VAX.) For more information on lsr's, see http://www.smxinfo.com\articles\lsr_art\lsr_art.htm.

Ralph Moore
ralphm@smxinfo.com

We're New Zealanders Dammit!

Dear DDJ,

Regarding Michael Swaine's "Swaine's Flames" (DDJ, August 2001). Foster's Law still holds. Lucy Lawless is a New Zealander. No, we don't take kindly to this sort of thing.

Ngaire Atmore
natm001@ec.auckland.ac.nz

Correction

Due to a typographical error, an incorrect e-mail address was given for author Evgeniy Gabrilovich ("C++ Set-Theoretic Operations on Virtual Containers") in our October 2001 issue. He can be contacted at gabr@acm.org.

DDJ