The Eight Fs of Software Failure

It doesn't have to be that way

Disaster stories always make good news, but as observations, they distort reality. If we consider only software engineering disasters, we omit all those organizations that are managing effectively. But good management is so boring! Nothing ever happens worth putting in the paper. Or almost nothing. Fortunately, we occasionally get a heart-warming story such as Financial World telling about Charles T. Fisher III of NBD Corporation, one of their award-winning CEO's for the Eighties:

"When Comerica's computers began spewing out erroneous statements to its customers, Fisher introduced Guaranteed Performance Checking, promising $10 for any error in an NBD customer's monthly statement. Within two months, NBD claimed 15,000 new customers and more than $32 million in new accounts."

What the story doesn't tell is what happened inside the Information Systems department when they realized that their CEO, Charles T. Fisher III, had put a value on their work. I wasn't present, but I could guess the effect of knowing each prevented failure was worth $10 cash.

The Second Rule of Failure Prevention

One moral of the NBD story is that those other organizations do not know how to assign meaning to their losses, even when they finally observed them. It's as if they went to school, paid a large tuition, and failed to learn the one important lesson—the First Principle of Financial Management, which is also the Second Rule of Failure Prevention:

A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars.

Will these other firms ever realize that exposure to a potential billion dollar loss has to be the responsibility of their highest ranking officer? A programmer who is not even authorized to make a long distance phone call can never be responsible for a loss of a billion dollars. Because of the potential for billion dollar losses, reliable performance of the firm's information systems is a CEO level responsibility.

Of course I don't expect Charles T. Fisher III or any other CEO to touch even one digit of a COBOL program. But I do expect that when the CEOs realize the value of trouble-free operation, they'll take the right CEO-action. Once this happens, this message will then trickle down to the levels that can do something about it—along with the resources to do something about it.

Learning from others

Another moral of all these stories is that by the time you observe failures, it's much later than you think. Hopefully, your CEO will read about your exposure in these case studies, not in a disaster report from your office. Better to find ways of preventing failures before they get out of the office.

Here's a question to test your software engineering knowledge:

What is the earliest, cheapest, easiest, and most practical way to detect failures?

And here's the answer that you may not have been expecting:

The earliest, cheapest, easiest, and most practical way to detect failures is in the other guy's organization.

Over more than a half-century in the information systems business, there have been many unsolved mysteries. For instance, why don't we do what we know how to do? Or, why don't we learn from our mistakes? But the one mystery that beats all the others is why don't we learn from the mistakes of others?

Cases such as those cited above are in the news every week, with strong impact on the general public's attitudes about computers. But they seem to have no impact at all on the attitudes of software engineering professionals. Is it because they are such enormous losses that the only safe psychological reaction is, "It can't happen here (because if it did, I would lose my job, and I can't afford to lose my job, therefore I won't think about it)."

The Significance of Failure Sources

If we're to prevent failures, then we must observe the conditions that generate them. In searching out conditions that breed failures, I find it useful to consider that failures may come from the following eight F's: frailty, folly, fatuousness, fun, fraud, fanaticism, failure, and fate. The following is a brief discussion of each source of failure, along with ways of interpreting its significance when observed.

But before getting into this subject, a warning. You can read these sources of failure as passing judgment on human beings, or you can read them as simply describing human beings. For instance, when a perfectionist says "people aren't perfect," that's a condemnation, with the hidden implication that "people should be perfect." Frankly, I don't think I'd enjoy being around a perfect person, though I don't know, because I've never met one. So, when I say, "people aren't perfect," I really mean two things:

"People aren't perfect, which is a great relief to me, because I'm not perfect."

"People aren't perfect, which can be rather annoying when I'm trying to build information system. But it will be even more annoying if I build my information system without taking this wonderful imperfection into account."

It may help you, when reading the following sections, to do what I did when writing them. For each source, ask yourself, "When have I done the same stupid thing?" I was able to find many examples of times when I made mistakes, made foolish blunders, made fatuous boo boos, had fun playing with a system and caused it to fail, did something fraudulent (though not, I hope, illegal or immoral), acted with fanaticism, or blamed fate for my problems. Once, I actually even experienced a hardware failure when I hadn't backed up my data. If you haven't done these things yourself (or can't remember or admit doing them), I'd suggest that you stay out of the business of managing other people until you've been around the real world a bit longer.

Frailty

Frailty means that people aren't perfect. They can't do what the design calls for, whether it's the program design or the process design. Frailty is the ultimate source of software failure. The Second Law of Thermodynamics says nothing can be perfect. Therefore, the observation that someone has made a mistake is no observation at all. It was already predicted by the physicists.

It was also measured by the psychologists. Recall case history 5, the buying club statement with the incorrect telephone number. When copying a phone number, the programmer got one digit incorrect. Simple psychological studies demonstrate that when people copy 10-digit numbers, they invariably make mistakes. But everybody knows this. Haven't you ever copied a phone number incorrectly?

The direct observation of a mistake has no significance, but the meta-observation of how people prepare for mistakes does. It's a management job to design procedures for updating code, acknowledging facts of nature, and seeing that the procedures are carried out. The significant observation in this case, then, is that the managers of the mail-order company failed to establish or enforce such procedures.

In Pattern 1 and Pattern 2 organizations, for instance, most of the hullaballoo in failure prevention is directed at imploring or threatening people not to make mistakes. This is equivalent to trying to build a kind of perpetual motion machine—which is impossible. Trying to do what you know is impossible is fatuousness, which we will discuss in a moment.

After a mistake happens, the meta-observation of the way people respond to it can also be highly significant. In Pattern 1 and Pattern 2 organizations, most of the response is devoted to establish blame and then punishing the identified "culprit." This reaction has several disadvantages:

• It creates an environment in which people hide mistakes, rather than airing them out.

• It wastes energy searching for culprits that could be put to better use.

• It distracts attention from management responsibility for procedures that catch failures early and prevent dire consequences.

The third point, of course, is the reason many managers favor this way of dealing with failure. As the Chinese sage said,

When you point a finger at somebody, notice where the other three fingers are pointing.

Folly

Frailty is failing to do what you intended to do. Folly is doing what you intended, but intending the wrong thing. People not only make mistakes, they also do dumb things. For example, it's not a mistake to hard code numerical billing constants into a program as was done in the public utility billing cases. The programs may indeed work perfectly. It's not a mistake, but it is ignorant because it may cause mistakes later on.

Folly is based on ignorance, not stupidity. Folly is correctable, whereas frailty is not. For instance, it is folly to pretend not be frail, that is, to be perfect. Either theoretical physics or experience in the world can teach you that nobody is perfect.

In the same way, program design courses can teach you not to hard code numerical constants. Or, you can learn this practice as an apprentice to a mentor, or from participating in code reviews where you can observe good coding practices. But it's management's job to establish and support training, mentoring, and technical review programs. If these aren't done, or aren't done effectively, then you have a significant meta-observation about the management of failure.

Fatuousness

It is worse than folly to manage a foolish person and not provide the training or experience needed to eradicate the foolishness. We call such behavior "fatuousness." ("Utter stupidity" would be better, but it doesn't start with F.) Fatuousness is utter stupidity, or being incapable of learning. Fatuous people—which occasionally includes each of us—actively do stupid things and continue to do them, time after time. For example,

Ralston, a programmer, figures out how to bypass the configuration control system and zaps the "platinum" version of an about-to-be-released system. The zap corrects the situation he was working on, but results in a side-effect that costs the company several hundred thousand dollars.

The loophole in configuration control is fixed, but on the next release, Ralston figures out a new way to beat it. He zaps the platinum code again, producing another 6-figure side effect.

Once again, the new loophole is fixed. Then, on the third release, Ralston beats it again, although this time the cost is only $45,000.

The moral of this story is clear. The fatuous person will work very hard to beat any "idiot-proof" system. Indeed, there is no such thing as an "idiot-proof" system, because some of the idiots out there are unbelievably intelligent.

There's no protection against fatuous people in a software engineering organization except to move them into some other profession. What significance do you make of this typical situation?

Suppose you were Ralston's manager's manager. Hunt, his immediate manager, complains to you, "This wouldn't have happened if Ralston hadn't covertly bypassed our configuration control system. I don't know what to do about Ralston. He goes out of his way to do the wrong thing, beating all our systems of protection. And he's done this three times before, at least."

What was the significant part of this story? Ralston, of course, has to be moved out, but that's only the second most important part. Hunt—who has identified a fatuous employee and hasn't done anything about it—is doubly fatuous. Hunt needs to be recycled out of management into some profession where his utter stupidity doesn't carry such risk. If you delay in removing Hunt until he's done this with three employees, what does that make you?

Fun

Ralston's story also brings up the subject of fun. Some readers will rise to the defense of poor Ralston, saying, "He was only trying to have a little fun by beating the configuration control system." Well, I'm certainly not against fun, and if Ralston wants to have fun, he's entitled to it. But the question Ralston's manager has to ask is, "What business are we in?" If you're in the business of entertaining your employees at the cost of millions, then Ralston should stay. Otherwise, he'll have to have his fun hacking somewhere else.

In the actual situation, Ralston wasn't trying to have fun—at least that wasn't his primary motivation. He was, in fact, trying to be helpful by putting in a last minute "fix." Well-intentioned, but fatuous, people like Ralston are not as dangerous as people who are just trying to have a good time. Hunt could have predicted what Ralston that going to to to be helpful, but

Nobody can predict what somebody else will consider "fun."

Here are some items from my collection of "fun" things that people have done, each of which has resulted in costs greater than their annual salary:

• created a subroutine that flashed all the lights on the mainframe console for 20 seconds, then shut down the entire operating system.

• created a virus that displayed a screen with Alfred E. Neumann saying "What, me worry?" in every program that was infected.

• altered the pointing finger in a Macintosh application to point with the second finger, rather than the index finger. The testers didn't notice this obscene gesture, but thousands of customers did.

• diddled the print spooler so that in December, "Merry Christmas" was printed across a few tens of thousands of customer bills, as well as all other reports. The sentiment was nice, but happened to obliterate the amount due, so that customers had to call individually to find out how much to pay.

The list is endless and unpredictable, which is why fun is the most dangerous of all sources of failure. There are only two preventives: open, visible systems and work that is sufficient fun in and of itself. That's why fun is primarily a problem of Pattern 2 organizations, which seldom meet either of those conditions.

Fraud

Although fun costs more, software engineering managers are far more afraid of fraud. Fraud occurs when someone illegally extracts personal gain from a system. Although I don't mean to minimize fraud as a source of failure, it's an easier problem to solve than either fun or fatuousness. That's because it's clear what kind of thing people are after. There are an infinite number of ways to have fun with a system, but only a few things worth stealing.

I suggest that any software engineering manager be well read on the subject of information systems fraud, and take all reasonable precautions to prevent it. The subject has been well covered in other places, so I will not cover it further.

I will confess, however, to a little fraud of my own. I have often used the (very real but minimal) threat of fraud to motivate managers to introduce systematic technical reviews. I generally do this after failing to motivate them using the (very real and significant) threat of failure, folly, fatuousness, or fun.

Fanaticism

Very infrequently, people try to destroy or disrupt a system, but not for direct gain. Sometimes they are seeking revenge against the company, the industry, or the country for real or imagined wrongs done to them. Fanaticism like this is very hard to stop, if the fanatic is determined, especially because, like "fun," you never know what someone will think is an offense that requires revenge.

Fanaticism, like fraud, is a way of getting the attention of management. With reasonable precautions, however, the threat of terrorism can be reduced far below that of frailty. Frailty, however, lacks drama. In any case, many of the actions that protect you against frailty will also reduce the impact of terrorism. Besides, I cannot offer you any useful advice on how to observe potential terrorists in your organization. That would be "profiling."

Failure (of Hardware)

When the hardware in a system doesn't do what it's designed to do, failures may result. To a great extent, these can be overcome by software, but that is beyond the scope of this book. Fifty years ago, when programmers complained about hardware failures, they had a 50/50 chance of being right. Not today. So, if you hear people blaming hardware failures for their problems, this is significant information. What it signifies can be chosen from this list, for starters:

1. There really aren't significant hardware failures, but your programmers need an alibi. Where there's an alibi, start looking for what it's trying to conceal.

2. There really are hardware failures, but they are within the normally expected range. Your programmers, however, may not be taking the proper precautions, such as backing up their source code and test scripts.

3. There really are hardware failures, and you are not doing a good job managing your relationship with your hardware supplier.

4. Failure attributed to hardware may actually be caused by human error—unexpected actions on the part of the user. These are really system failures.

 Fate

This is what most bad managers think is happening to them. It isn't. When you hear a manager talking about "bad luck," substitute the word "manager" for "luck." As they say in the Army,

There are no bad soldiers, only bad officers.

What's Next?

This three-part essay is now finished, but the topic is far from complete. If you want more, note that the essay is adapted from a portion of Chapter 2 from Responding to Significant Software Events. 

This book, in turn, is part of the Quality Software Bundle, with is an economical way to obtain the entire nine volumes of the Quality Software Series (plus two more relevant volumes).

I'm sure you can figure out what to do next. Good luck!

The Universal Pattern of Huge Software Losses

Apology: This post was supposed to appear automatically as a follow-up to my three cases of large, costly software failures, but evidently I had a software failure of my own so the google scheduler didn't do what I thought I asked for. So, here is the first follow-up, a bit late. I hope it's worth waiting for.

To complete my data gathering, I'll present two more loss cases, then proceed to describing the pattern that governs all of these cases, followed by the number one rule for preventing such losses in the first place.

Case history 4: A broker's statement

I know this story from the outside, as a customer of a large brokerage firm:

One month, a spurious line of $100,000.00 was printed on the summary portion of 1,500,000 accounts, and nobody knew why it was there. Twenty percent of clients called about it, using perhaps 50,000 hours of account representative time, or $1,000,000 at least. An unknown amount of customer time was used, and the effect on customer confidence was unknown. The total cost of this failure was at least $2,000,000, and the failure resulted from one of the simplest known errors in COBOL coding: failing to clear a blank line in a printing area.

Case history 5: A buying club statement

I know this story, too, from the outside, as a customer of a mail-order company, and also from the inside, as their consultant:

One month, a new service phone number for customer inquiries was printed on each bill. Unfortunately, the phone number had one digit incorrect, producing the number of a local doctor instead of the mail-order company. The doctor's phone was continuously busy for a week until he could get it disconnected. Many patients suffered, though I don't know if anyone died as a result of not being able to reach the doctor. The total cost of this failure would have been hard to calculate except for the fact that the doctor sued the mail-order company and won a large settlement. One of the terms of the settlement was that the doctor not reveal the amount, but I presume it was big enough. The failure resulted from an even simpler error in COBOL coding: copying a constant wrong.

The Universal Pattern of Huge Losses

I'll stop here, because I suspect you are getting bored with reading all these cases. Let me assure you, however, that they were anything but boring to the top management of the organizations involved. Rather than give a number of similar cases I have in my files, let's consider each case as a data point and try to extract some generalized meaning.

Every such case that I have investigated follows a universal pattern:

1. There is an existing system in operation, and it is considered reliable and crucial to the operation.

2. A quick change to the system is desired, usually from very high in the organization.

3. The change is labeled "trivial."

4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.

5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.

6. The change is put directly into the normal operations.

7. The individual effect of the change is small, so that nobody notices immediately.

8. This small effect is multiplied by many uses, producing a large consequence.

The Universal Pattern of Management Coping With a Large Loss

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.

10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.

11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job.

12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.

13. Higher managers are left untouched. After all, what could they have done?

The First Rule of Failure Prevention

Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:

• "This is a trivial change."

• "What can possibly go wrong?"

• "This won't change anything."

When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention.

Nothing is too small to not be worth observing.

What's Next?

Now that you're familiar with the pattern, we'll take a breather until the next post. There I'll provide other guides for preventing such failures.

Note

This essay is adapted from a portion of Chapter 2 from Responding to Significant Software Events.

This book, in turn, is part of the Quality Software Bundle, with is an economical way to obtain the entire nine volumes of the Quality Software Series (plus two more relevant volumes).

- See more at: http://secretsofconsulting.blogspot.com/#sthash.SRafTDef.dpuf

Some Very Expensive Software Failures

Why Concentrate on Failure?

"So long as a man attends to his business the public does not count his drinks. When he fails they notice if he takes even a glass of root beer." - Corra May Harris

Logically, direct measurement of value should be the first place an organization starts to look at itself, but that's not how it usually happens. Instead, the trigger for most organizations to embark on some self-examination is failure—either one whale of a failure or thousands of annoying failure mosquitoes.

This concentration on failure may seem illogical—and may be illogical in many circumstances—but it does fit with our understanding of quality as subjective value. Of all the troublesome aspects of using computers, failures are by far the most annoying to the most people. Without ever conducting a detailed impact case study, or even a greatest single benefit study, people know that they don't like it when their computer fails. Thus, customers heap abundant praise and appreciation on the software organization that doesn't fail them.

Of course, the definition of failure changes with time, as expectations change. Once customers become accustomed to a certain level of service, a lapse from that level becomes a failure. Some customers have come to expect a succession of "breakthroughs" in software, so that achieving only a modest gain is seen as a failure. Thus, the first step in managing failures is to manage customer expectations—but that's always the first step in managing quality.

What Do Failures Cost?

Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In this section, we'll take a look at a few examples that should convince you.

Case history 1: A national bank

The national bank of Country X issued loans to all the banks in the country. Each loan was confirmed by a telegram showing the amount of the loan, the repayment conditions, and the interest rate. The telegram became the legal loan document for the loan. The COBOL program that composed and sent these telegrams had been in operation for almost 15 years, and had worked flawlessly. Somebody noticed, however, that the serial number field would run out of digits and begin duplicating serial numbers within a few months. As each loan was legally identified by the serial number on the telegram, duplication could not be allowed.

Management directed that the serial number field be expanded. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Expand the serial number field by two digits." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

Some time later, a financial analyst noticed a slight discrepancy between estimated loan receipts and actual loan receipts. After much searching, it was discovered that the serial number expansion had overlaid the low order digits of the interest rate field, causing the final two digits of every interest rate to be truncated to "00." Although the difference between 7.3845% and 7.3800% is quite small, when you are lending hundreds of billions of dollars, it quickly adds up to something significant. In this case, it added up to more than a billion dollars that the national bank could never recover.

Case history 2: A public utility

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program.

Management directed that the constants be updated. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Replace these constants in the program." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

Some time later, the Comptroller's office noticed a slight discrepancy between estimated receipts and actual receipts. After much searching, it was discovered that two low order digits in one of the constants had been entered with "75" transposed to "57", causing a number of the bills to be short by a small amount. Billing millions of customers, this small difference added up to X dollars that the utility could never recover.

The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.

Case history 3: A state lottery

I know of this one through the public press, so I can tell you that it's about the New York State Lottery:

A few years ago, the New York State legislature authorized a special lottery to raise extra money for some worthy purpose. As this special lottery was a variant of the regular lottery, the program to print the lottery tickets had to be modified. Fortunately, all this involved was changing one digit in the existing program.

Management directed that the change be made. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Change this digit to a five." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

A few weeks later, when ticket sales were in full swing, one of the players bought two tickets and noticed that they had identical numbers. As there were supposed to be no duplicates in this lottery, he brought his tickets to the Daily News, which printed a photo of him and his two tickets on the front page. Public confidence in the lottery plunged, and the explanation that the error was "trivial" did not restore public confidence. In order to satisfy the public outcry, all lotteries were shut down pending the report of a blue ribbon investigating committee (this is government, after all). Altogether, it took 11 months for the matter to be resolved and the lotteries to be reestablished. At that time, the lotteries had been netting the state about $4 million to $5 million per month, so the total loss of revenue was estimated between $44 million and $55 million.

What's Next?

I have many more cases of failure, but to keep this blog short, I'll pause here. In my next blog essay, I'll give a few more cases, then describe the universal pattern of huge losses. After that, I'll provide some guides for preventing such failures.

Note

This essay is adapted from a portion of Chapter 2 from Responding to Significant Software Events. 

This book, in turn, is part of the Quality Software Bundle, with is an economical way to obtain the entire nine volumes of the Quality Software Series (plus two more relevant volumes).

How You Can Help Your Favorite Author

In spite of popular myths, writing books is a tough way to make a living. The writing itself is tough enough for most people, which is probably why most people don't consider becoming writers themselves. But for all the writers I know, the writing is probably the easiest part of the job. The hard part is promoting your books so people will buy them and, hopefully, will read them.

One of my writing buddies recently released a new book, A Murder of Crows. To accompany the release, she wrote a blog essay in which she said, "I am, of course, in panic mode, because I have a release-day checklist in which I do more than whisper a quiet announcement on Facebook and slink back into my hidey hole, as usual, so make snarky comments and post nerdy links. The dreaded promotion phase of writing. I think I know like two writers who enjoy promoting themselves. The rest of us are terrified."

I'm not one of those two writers. I don't enjoy promoting myself, not because I dread it, but because I don't enjoy doing things I don't do well. I didn't adopt a writing career because I was a good self-promoter. Fortunately, I have done quite well in my writing career because other people do a good job of promoting my stories.

That's true for most any successful writer. They succeed because their fans promote them. So, if you would like to help your favorite author, here are some options:

1) Buy their book today. With the advent of e-books, this act is easier and cheaper than it's ever been in the past. Various services report the  sales of books, and the more that are sold, the more the stores promote them. The more people who buy the book, the better it seems to look to the stores' algorithms and the more visible they make those books to complete strangers who happen to be looking for something to read. Buying the book is not required, but it should be a huge help to your author's reputation.

2) Ask the for a free copy of the book. For instance, I have formats set up for all major ereaders as well as on your computer. If you have no intention of reading the book but want to pass it on to someone who miiiiiight want it like six years from now, I have no problem with that. Ask away

3) Review the book at Amazon, Goodreads, LibraryThing, Smashwords, on your blog or other social media, on the back of a napkin, sealed up into a bottle and tossed into the ocean...[Note: Anywhere you mention the book—or link to it—on the Internet helps brainwash Google and other search engines into making it just slightly more visible.]

4) Pass the word. There’s a local commercial that always ends up with, “If you like our service, tell a friend. If you don’t, tell me.” That’s it exactly.

As far as social media goes, you may copy the picture of the cover off the author's blog and use it to help promote the book. (Most social media give extra weight to posts with pictures attached, which is why you see so many dang cats).

5) Sign up for the author's mailing list, which might produce a newsletter or other forms of information about the book or other books by the same or similar authors.

6) Chat with the author. Dayle says, and I agree: "I will listen to you complain about/praise the book. I will take typo oopsies if you catch any in the book. I will take invitations to write on your blog. I will talk with your book group. I will send free copies of books to libraries. If you have a favor to ask, ask it. Because trading favors is what makes the writing world go ’round.

7) Give the author hugs. Appreciative feedback encourages authors to write more and better books and stories.

In summary, to help your favorite author,

1. buy books
2. review someplace
3. tell a friend
4. give the author hugs

An Offer of Free Books to Reviewers

That summarizes (or plagiarizes) Dayles blog post. Now here's something of my own. I've always offered free books to reviewers, but don't always receive reviews in return. In fact, my experience and that of author colleagues is this: Only about one in three (1/3) of free books produce reviews. The rest produce nothing. So, I'm going to try a slightly different policy for reviewers, as follows:

1. You obtain one of my books (buy, beg, borrow, steal, or find laying on the sidewalk).
2. You read the book, or at least attempt to read it.
3. You write a review telling what you think others ought to know about the book. The review can be long or short, favorable or unfavorable, serious or funny.
4. You submit the review to be published somewhere, and also send a copy to me.
5. As your reward, I will send you two of my ebooks—you have dozens of books to choose from. Tell me your choices when you send me the copy of your review. You will receive your reward a day or two later.
6. (You can then repeat the process by reviewing one or both of your reward books. You can repeat until I have no more books with which to reward you.)

That's all there is to it. You can find all of my ebooks at <https://leanpub.com/u/jerryweinberg>—there are currently 44 books listed there, so you won't run out quickly.

And by the way, if I'm not one of your favorite authors, check with your favorites and ask what kind of reward they offer. The important thing is to support those writers you love, so the world can share your pleasure.

Free Books for Gift Giving

At this point in my professional life, at my advanced age, most of what I do professionally is teach workshops and write—mostly write. I don't write for money. All my writing income is given to charity: animal rescue, research on animal health, and civil liberty education (over $500,000, so far).

I write to pass along what I've learned, just as others have passed along their learnings to me. My goal is to reach as many readers as possible. Consequently, I'm always trying to think of ways to reach new readersm, and for this holiday season, I've thought of a way you can help me reach that goal.

Here's the deal. When you buy one of my ebooks, you can easily copy that book and give it to your friends and colleagues. If my primary interest was the money, I wouldn't be happy to know you're copying the ebook. But, although I do want money to go to my charities, I'm pleased that that a free copy has gone to someone who might otherwise not even know it exists.

So, this year, when you buy one of my books, I encourage you to copy it and give it to someone who might otherwise not know it, or could not afford it.

Yes, I know you could do this without my encouragement, but I also know that some readers don't feel right about taking something for free. And, generally, that's not entirely honest, so I'm not encouraging you to do this for other authors without their permission. But for my books, you have my permission, so go ahead and copy with a clear conscience.

(If you want to "pay" me, drop me a little email note saying how many free copies you distributed. That will satisfy my curiosity, and might encourage me to make this offer every year.)

BARGAIN BUNDLES

To make this offer even more attractive, remember that I'm offering a list of bargain book bundles from Leanpub.com. Take a look at the books in each bundle by clicking one of these links:

Experiential Learning (3 volumes @$45)

Fable Bundle (2 volumes @$7.99)

Residue Class Mystery Series (3 volumes@$11.99)

Quantum Stringer Series (3 volumes@$14,99)

The Testers Library (8 volumes@$49.99)

Secrets of Consulting  (2 volumes@$14.99 )

Quality Software  (11 volumes@$49.99)

General Systems Thinker Bundle (5 volumes@$29.99 or less)

Requirements  (2 volumes@$14.99)

Using these bundles with the copying offer, you'll be able to fulfill an enormous gift list with minimal expense.

Gifts for Any Time, but Especially Now

Now that we're finished with that Black Friday and CyberMonday hysteria, it's time for my annual Christmas poem:

Twas the week before Christmas,

And all through the house,

Every creature was fretting

And starting to grouse.

Then from UPS

Came a gift flowerpot

From a friendly old colleague

Whose gift I'd forgot.  

But then I remembered:

Don't feel like a schnook

In just a few minutes

I can send a great book

No wrapping, no breakage,

No address to scrawl,

No trade-ins, no trouble,

'Cause one size fits all.

So boot up your browser,

And don't be a schnook.

In a fistful of keystrokes

You can send a fine book.

Naturally, I recommend one of my novels for a fun read and fitting gift—perfect for smart adults and bright teenagers.

For just $6.99 each (or less when buying more than one), you can go to http://www.thewomenofpower.org to read about each story and what reviewers said. Then you can send your friends engaging, exciting stories, each one that also carries one or more science/technology themes. 

These novels are my attempts to put the science back in science fiction and the techno back in techno-thrillers.

The Residue Class Mysteries Themes

The Freshman Murders: Computers, Culture, Genealogy

Where There's a Will There's a Murder: Mathematics, Anthropology

The Death Lottery: Randomness, Programming, Espionage

The Quantum Stringers Series Themes

Quantum String Quartet: Physics, Social Psychology

Quantum String Sextet:: Team Building, Communication

Quantum String Band:: Space Travel, Psychology

The Women of Power Series Themes

Mistress of Molecules: Chemistry, Politics

The Hands of God: Parallel Computing, Neurophysiology, Prosthetics

Earth’s Endless Effort: Unconventional Computers, Alien Contact

The Aremac Project Series Themes

The Aremac: Software Development, Testing, Security

Aremac Power: Risks and Rewards of Invention

And, of course, Computers in every story!

And if you've already gifted everyone on your list, I invite you to try one of my novels for yourself. As always, if it doesn't fit for you, I’ll gladly return your money.

Have a wonderful Holiday every day,

Jerry

p.s. You can also gift your techie friends with some of my non-fiction ebooks: See Leanpub.com