Wednesday, September 21, 2011

Why English Will Never Be 100% Automated: Example

One of the nice features of the Kindle eBook service is they way they copy-edit some of their better-selling books. This can be a particularly important service for print books that have been scanned to make eBooks. For instance, Amazon recently wrote about my Kindle book, An Introduction to General Systems Thinking:

Typo issues exist that may have been caused by an Optical Character Recognition (OCR) problem. Few examples are given below:

loc 1561 - "T call them" should be " I call them".
loc 2946 - "But 1 still can't" should be "But I still can't".
loc 3351 - "Shasta the liger" should be "Shasta the tiger".

Please look for the same kind of errors throughout the book.

The first two instances are common OCR (Optical Character Recognition) errors: "T" for "I" and "1" (the numeral) for "I" (the capital letter).

The third example is a not quite so common OCR error, "l" (the letter) for "t". And, in this case, it's not an error at all.

The sentence in question was:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the liger at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

Still, the sentence contains a more subtle error: the failure of the author (me) to account for the mental state of the typical reader, for whom the term "liger" may be unfamiliar. (Even though it is found in at least 16 on-line dictionaries.)

I corrected this much more subtle error by redrafting the questionable sentence as:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the "liger" at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

As I dealt with this situation, I kept sighing and thinking, "English will never be entirely automated."

And then I took a deep breath and thought, "I suppose I prefer it that way."

How about you? Would you like English to be entirely clear and logical?

An Introduction to General Systems Thinking

Saturday, September 17, 2011

Downgraded to Testing

Here's a letter I got from a friend overseas. I've altered any identifying information, for obvious reasons. I'm going to intersperse some comments as if I were conversing with Nicolai face-to-face.

Nicolai's Letter
One thing I still like to know from you about "Perfect Software and Other Illusions About Testing". Are there metrics or measurement criterias with which you can measure the success of Testing in the software development life cycle (SDLC)?

I am in a struggle with my employer to change my position from a system developer (am working for the auto parts industry / manufacturing planning and execution) into a software tester. I made that decision after I recognized that this job much more fits to my personality type than doing the implementation.

That recognition is an excellent starting point for solving your problems. Many people don't really know consciously what they really would like to do.


But let me come back to my main concern nowadays. My problem now is that in my country and especially in my company, this issue of Testing is new. My boss's understanding of it is low and hence he wants to reduce my salary around 10%.

Sorry, that's not why he wants to reduce your salary. That's his excuse for taking advantage of your wish to change jobs. He simply sees an opportunity to save some money at your expense. Yes, if he understood anything about testing, he should raise your salary by 10%—or more.

That's in contrast with the huge losses we have because of NOT using Testing at all in our processes.

Oh, my. Your company is at Level 0 when it comes to Testing. Oblivious! That is definitely not the place to be if you wish to make a career, long or short-term, in Testing.

Anyway I will not stay long there anymore.

That's the wisest thing you've said so far.

I will try to setup my own company (industrial import export trading consultancy).

That's an ambitious goal, and probably long-term. You cannot afford to stay any longer in this unbelievably bad company with this even more unbelievable manager.

But in the meantime I have to feed my family and I need an advice from how I can measure the success of Testing. Based on such criteria, I can improve my salary negotiation and make Testing much more tangible to everyone even myself. Once I have the criteria or indicators, I can make a some percent part of my salary depending on the success of implementing Testing into the SDLC. I think that is fair enough.

Your boss has demonstrated he has no interest in "fair enough." And no interest in your career or your family. Your approach is all wrong. You should first find yourself a job in an organization that already values Testing, at least slightly.

In my experience, an organization like yours is never (at least in your working lifetime) going to value testing enough to value you, or pay you what you're worth to them. Nor will it be a good place to learn the profession. All you will learn is what I'm telling you now: that is, you shouldn't stay in this job a moment longer than you must in order to see that your family is fed. (For example, if your wife works, see if you can simplify your finances so you can live on her income, at least for a short time.)

But, in any case, you should immediately begin searching for a new job, in a much more compatible place. (And do it without letting anybody know. The kind of boss you have will not react well to news that you're seeking a new position. Let him know when you're saying goodbye, when you've already been hired by the new place.

What would be such indicators of a successful integration of Testing into the software development life cycle (SDLC)? I know you use the FFR, but this says something about the quality of the software development team. What would be indicators that say something about the quality of the software test team?

Any hints from you are very welcome.

What you need now is one or more ways to put a cost on the software errors that are already reaching your users. (For example, you can use methods described in Quality Software series of eBooks—particularly Volumes 3 and 4: How to Observe Software Systems and Responding to Significant Software Events.)

Use these methods to arrive at average and extreme costs of each software bug that leaves your development group. And a count of how many bugs you ship with how much software. Then you can produce a report that says, "If our Testing is X% efficient at finding bugs, and if our developers are Y% efficient at fixing them before release, then we can expect to save Z-dollars by having a Testing group."

If you really do no Testing now in your SDLC, you can expect Z to be a very large amount. (And if it's not a very large amount, then Testing is really not important there, and you shouldn't be working there.)

Even if you're already in a Testing group, you should make such measurements, so you can get the support you need. And be appreciated.

I hope this helps.

Responding to Significant Software Events

How to Observe Software Systems