The Assumption of Fixed Requirements

Note 1: This post is extracted from Chapter 9 of my book, CHANGE: Planned and Unplanned.

Note 2: This book was written for project leaders in high-tech industries, but writers are also project leaders, and writing certainly requires great skill and precision. For writers, requirements may originate from publishers, agents, and for-hire customers—any of whom can cause unending grief by changing those requirements for a writer who has assumed they were fixed.

Until recently, the computing industry seems to have avoided the subject of requirements the way a debutante might avoid the subject of indigestion. We knew such things existed, but if we didn't think about them, perhaps they would simply take care of themselves.

Many of the classic early papers in software engineering were based on the position:

This is how we would design and build software (if we had unchanging requirements.)

[For writers: each of us has her/his own process for writing, but for many of us, that process is also based on having unchanging requirements. If someone changes our task, we may be thrown off our game, and into write-stopping turmoil.]

For instance, many of the early papers on structured programming were based on the Eight Queens Problem, a problem of fixed definition with no input whatsoever. Many papers on recursive programming were based on the Towers of Hanoi problem, another problem of fixed definition with no input whatsoever. The more recent Cleanroom methodology has the same basis: "The starting point for Cleanroom development is a document that states the user requirements." The following quotation from Parnas and Clemens shows how deeply this assumption runs, even in the most sophisticated process designers.

Usually, a requirements document is produced before coding starts and is never used again. However, that has not been the case for [the software requirements for the A-7E Aircraft]. The currently operational version of the software, which satisfies the requirements document, is still undergoing revision. The organization that has to test the software uses our document extensively to choose the tests that they do. When new changes are needed, the requirements document is used in describing what must be changed and what cannot be changed. Here we see that a document produced at the start of the ideal process is still in use many years after the software went into service. The clear message is that if documentation is produced with care, it will be useful for a long time. Conversely, if it is going to be extensively used, it is worth doing right.

Parnas and Clemens describe the benefits of returning after design to create a requirements document as if it had been present from the beginning.

In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing they should have unchanging requirements before starting any project. This model or belief is what I call the Assumption of Fixed Requirements, an assumption that is a misreading of these classical works. These classics were not addressing the entire process of software engineering, but only selected parts of that process. What they are teaching us is how to translate requirements into code, once we have reliable requirements.

Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past decades. Because of that attention, however, it is no longer the most difficult part of the process. Many organizations know how to do this part quite well, but the quality of their products does not adequately reflect their coding prowess.

In recent internal studies of serious quality problems, three different clients of mine arrived at quite similar conclusions. They divided the sources of the most serious problems into a number of categories, including coding and gathering requirements. In all cases, coding contributed least of all categories to quality problems, and my clients would perhaps do better to work on the less glamorous job of improving their logistics processes. Perhaps these rather advanced organizations are not typical of all software engineering organizations. They still have a lot to learn about coding and especially design, but in each case, the majority of their serious problems stem from requirements.

Software engineers and their customers perceive quality differently, and this table accounts in large part for that discrepancy in perception. Over the past decades, engineers have seen coding faults drop dramatically as a result of their quality improvement efforts. The customers, however, have not seen a comparable decrease in the number of requirements problems, and so do not perceive the same increase in quality as the engineers, who are paying attention to their own priorities—which don't happen to coincide with their customers' priorities. The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding—even though that was the improvement process that brought them as far as they've come.

Writers Are Losing the Fight Again

Dean Wesley Smith has written another scathing post about "agents" trying to scam writers in "the new world of publishing." Please read it: http://www.deanwesleysmith.com/?p=4096&cpage=2#comment-9194



It's a terrific post, which it has in common with all Dean's posts, but this time he made one little mistake, so I had to write a comment on his blog.

But there are so many comments (as there should be, and you should read them all), you might miss mine, so I'm repeating it here.


Dean,

I’ve been thinking about this whole scheme and decided it’s not a scam at all. It’s actually a terrific idea, with only one slight flaw.

All that it needs to make it a fair deal is to make it symmetrical. In particular, the agents have the right idea about expenses. This is a business, and it’s quite right that the partners in such a deal should be reimbursed for their expenses before any royalties are distributed.

So, I’m looking for an agent who will write a contract with me where s/he gets expenses and so do I. Let’s see, what are my expenses?

Well, there’s toner for my printer.

And several reams of paper.

And the printer itself.

And the computer.

And the software.

And my office, and its furnishings.

Let’s see. What have I forgotten. Oh yes, there’s about 20 years of schooling so I could learn how to write. Let’s figure conservatively about $50,000 per year. It’s probably a lot more, but we don’t want to take advantage of the poor agent, so we just have $50,000 times 20, which seems to come to $1,000,000 before I could write a word.

Now of course, my schooling was a long time ago, so if I hadn’t spent that money learning how to write, I could have put it into US Treasury bonds and easily earned, say, 6% on the average. And I finished my schooling roughly 50 years ago, which means the $1,000,000 would have doubled roughly 4 times since then, making $16,000,000 today.

Don’t you just love this calculating “expenses”? (That's an important part of the new agent scam contract.)

The way I figure is I’d happily sign with an agent who’d give me $16,000,000 up front to cover my expenses.

Or, since I’ve published roughly 100 books, I’d be willing to take $160,000 up front from any agent wanting to contract with me to handle a book of mine.

So, agents, if you’re reading this, better hurry and get your cash in hand and contact me before all those other agents beat you to the punch.

Yes, Dean, I’m sorry, but you’re just going to have to write a retraction saying what a good deal these new agent ideas are for writers. Agents, please insist on it.

Oh, and by the way, here are two of my most recent eBooks, which you can sample at http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg and purchase them there, or at Amazon or Barnes and Noble.

Project Mercury

I was one of the workers on Project Mercury. My job was to design and implement the space tracking network, and particularly the multiprogrammed operating system that ran the entire network. Many readers have asked me about Mercury, so here's a little something courtesy of SPACE.com:


Source SPACE.com: All about our solar system, outer space and exploration

"Smashwords vs. Kindle?" Are Your Lights On?

Yesterday, Don Gause and I posted out book on problem definition, Are Your Lights On?—a book many have called a "classic."

Today, I ran across a perfect example of why the lessons in the book are so useful. On one of the writers' forums in which I participate, a reader posted a query entitled Smashwords vs. Kindle? Here it is:



Gemma, a writer, asks:

Can someone tell me what the benefits or advantages of publishing on Smashwords might be when Amazon, the number five most visited site in the USA, (according to Alexa.com) provides such a successful solution and so much higher traffic? To compare, Smashwords ranks 2,751 in terms of daily traffic. Amazon's "query popularity" is 86 out of 100, versus only 38 out of 100 for Smashwords. Amazon visitors spend an average of eight minutes on the site and view 8.8 pages while Smashwords visitors spend six minutes on the site and view 6 pages.

Still, I have found the folks on this list to be a savvy bunch, so I suspect there must be some hidden advantages or benefits of which I am unaware. Can anyone who has published on Smashwords help me out by sharing some benefits? I am about ready to put up some titles on Amazon and had decided to stick exclusively to that platform and to B & N, but maybe I am cutting off potential sales by not posting on Smashwords.

Perhaps someone else has the answer already:

One of the things Are Your Lights On? teaches is to use all the information you have. In this case, I had an earlier answer from another author, "Linda."

Linda offered this answer:

Yes, Amazon offers worldwide traffic, but Smashwords offers retail eBook outlets that we do not get at Amazon.  My books are directly at Amazon Kindle.  And then I have also added a number of my books and my husband's at Smashwords to take advantage of the retail outlets they distribute to.  At Smashwords I opt out of Amazon, and will continue to do so.  But Smashwords has not only their direct website, but the books are sent to the ebook retailers-- Kobo, Nook, Diesel, IPad, etc.  I love being able to check daily on my Kindle sales and be paid monthly by Kindle.  Royalty payments and sales via the Smashword's distributors are slower, depending on the retailer.

So the advantage is having more retail distribution (and hopefully sales) by putting your books at Smashwords, in addition to having them at Amazon Kindle.

Even good answers may not be complete.

Are Your Lights On? teaches:

"If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem."

Well, I really liked Linda's answer, but applying the Rule of Three, thought about how it could be improved.


Jerry adds to Linda's answer:


First of all, listen to Linda. She and her husband use exactly the same strategy Dani and I use. [Note from AYLO: Answers don't just have to be right, they have to be convincing. Supporting Linda's excellent answer is the first job a consultant has to do to be effective in this case.]

So, my first answer to Gemma is this: You've done your research, and done it well, but the data you've gotten happens to be irrelevant to this problem. The traffic each site receives doesn't really matter. What matters is selling books. Suppose Site A receives 1000 hits/day, and the average stay is 10 clicks, and they sell one book per day. Site B receives 10 hits per day, and the average stay is 1 click, and they sell two books per day. Which is better for you, the writer, A or B?
The answer is "none of the above." Why, because you don't have to choose. You can put your book on both A and B's sites, and sell three books.

On to the details:

Once you have the right problem definition, the solution is often trivial, as above. Since I can't verify my assumptions about Gemma's problem definition, I can add some other facts to support various definitions, such as,

1. A book sold at Smashwords gets a higher royalty than the same book sold at Kindle. For each $7 of Kindle royalty, the same sales on Smashwords earn $8.

2. Smashwords, as Linda says, distributes to many retail outlets that would be a pain to reach individually, and perhaps not worth the small sales they generate. Through SW, I reach them with zero extra effort.

3. In addition to extra retailers, I reach readers who don't use Kindle. As Linda says, SW formats automatically for just about every eReader known to humanity, again, at zero extra effort.

4. I don't know how many SW sales I would have through Amazon if SW weren't available, but I do know that through SW, I earn about 2/3 of what I earn through Kindle, so instead of, say, $1,000 through Kindle, I earn about $1,666 through the combined offering. (plus another $100 or so through Barnes and Noble, which you should also use.)

5. SW has a "coupon" feature that Amazon doesn't offer. That allows me to offer special price deals for a day, a week, a month, or whatever period of time I wish, for whatever price I wish. Very useful for marketing, and for reviewers. On Kindle/Amazon, a price change takes about three days to start, and three days to remove, and is seen by the whole world. On SW, the change takes place instantly, and can be removed instantly. I can offer it to one person, or 10, or 100, or to the entire internet world. My choice.

6. And, if you offer a book on SW, you can pull the book(s) any time you want. So, if it turns out you don't like something about SW, you're out of the deal instantly, whenever you want--not cost, no fuss. It's totally under your control.


Bottom Line

Yes, the book-selling business can be complicated, but this one's probably a no-brainer when you have all the facts—if I have the right problem definition. In a real consulting situation, I'd be able to talk with Gemma and verify that I understand her problem. Since I don't have access to her, I'm guessing that her implicit problem definition is wrong from the start.

Gemma, I think it's not "Smashwords vs. Kindle," but "Smashwords and Kindle" (and Barnes and Noble, and any other sites you wish, as long as they don't restrict your publishing elsewhere).

Perhaps the definition would have been better stated: "How can I achieve the best sales results for my eBook?"

P.S.

You can sample Jerry's books on Smashwords, including Are Your Lights On?, then buy them there or at any other site you might prefer. See and sample all my books on Smashwords (more going up all the time).

It Flies! Da Vinci's Dream Comes True

URL:  http://www.npr.org/blogs/krulwich/2011/04/11/135300971/...

by Robert Krulwich



This is not a trick. There are no invisible strings, no post production video fixes. What we have here is a graceful, flapping, unfeathery machine that looks and flies like a seagull. It was built by a team of engineers at a company called Festo in Germany, which specializes in factory automation, and for years now they've been doing what Leonardo dreamed of when he sat on those hills near Florence sketching birds: they copy from nature's designs.



Watch the movie! See the artificial bird fly! - Jerry

See this Amp at http://amplify.com/u/bywp6

How Fast is Fast Writing?

See my guest post on Ellis Vidler's blog: "How Fast is Fast Writing?" http://ow.ly/4ycjq

Learned Helplessness

My e-pal, L.M. May has written the most striking, useful blog post I've seen in a long time. L.M. says: "The following essay is about fiction writing and learned helplessness, ..." but L.M. "used to work in the software industry as a software tester," and so writes this essay with much the same qualifications I have—and combines the two main foci of this blog: writing and software creation. So, if you're a writer, or a software professional (or both), this essay is for you.

What is "learned helplessness," and what does it have to do with writing and software making? I'll leave the writing part to L.M., but I'd like to cover the software side briefly, before I send you off to read the essay, at:

http://lmmay.com/2011/04/03/fiction-writers-and-learned-helplessness/

L.M. quotes the Wikipedia definition, "Learned helplessness…means a condition of a human being or an animal in which it has learned to behave helplessly, even when the opportunity is restored for it to help itself by avoiding an unpleasant or harmful circumstance to which it has been subjected."

The essay was inspired by the reactions of some writers to the enormous technology-induced changes taking place in the publishing industry. (See, for example, my posts of Feb 27 and Feb 28, on this blog.) These writers had learned that the only real way to publish their books was the traditional way, as books printed on paper by a few large publishing companies. Mostly, they had put their entire business of writing in the hands of agents who dealt with these companies for them. Now, with e-publishing, they have an avenue for bypassing all those "helpers" (and their fat fees), but some of them, many of them, have learned to be helpless, and violently oppose the idea of standing on their own two feet as adults.

How does this relate to software professionals? If you really don't understand, I'm not sure I can explain it to you. To put it briefly and bluntly, have you ever allowed the "grown-ups" (the salespeople, the managers, the customers) to override your professional judgment because you felt helpless?

Did you ever agree to build some code in two months when you knew it would take at least five—and then silently take the blame when you made it in four?

Did you ever allow unqualified people to override your technical decisions, thinking you couldn't do anything about it?

Have you agreed to undertake testing software that was (to you) obviously unready for testing (or even patently untestable)?

Even if you've never experienced such events, have you ever watched others trapped by them, and not known how to help them?

If you know about such matters in your work, read L.M.'s essay about the psychology of learned helplessness, then come back here and be a voice in the conversation that follows.


And why here? LM explains:
"I keep my comments section off due to family and work commitments, but Dean Wesley Smith and Gerald M. Weinberg offered their blogs as sites where people could discuss this essay amongst themselves.  I will be checking in as often as I can to both their websites over the next few days to answer any questions."

I think we should divide the labor, with the writers' comments going to Dean's site (http://www.deanwesleysmith.com/) and the software people laying out their thoughts here. But you can choose where to hang out—both places, if you wish—and we'll see what comes of our sharing.

And, BTW, as you dig into this subject, you may want to try my ebook, Managing Yourself and Others, or at Amazon or Barnes & Noble.

Managing Yourself

This is why I wrote the book, "Managing Yourself and Others."



<https://www.smashwords.com/books/view/39685?ref=JerryWeinberg>



Mostly, it's about congruence!

Amplify’d from techcrunch.com

What’s The Most Difficult CEO Skill? Managing Your Own Psychology.

By far the most difficult skill for me to learn as CEO was the ability to manage my own psychology. Organizational design, process design, metrics, hiring and firing were all relatively straightforward skills to master compared to keeping my mind in check. Over the years, I’ve spoken to hundreds of CEOs all with the same experience. Nonetheless, very few people talk about it, and I have never read anything on the topic. It’s like the fight club of management: The first rule of the CEO psychological meltdown is don’t talk about the psychological meltdown.

At risk of violating the sacred rule, I will attempt to describe the condition and prescribe some techniques that helped me. In the end, this is the most personal and important battle that any CEO will face. Read more at techcrunch.com

 

See this Amp at http://amplify.com/u/bxclo

Knowing What to Leave Alone

I adapted this blog post from my new eBook, Becoming a Change Artist This little case example followed a number of other examples, as a kind of corrective to some peoples' ideas about how a change artist operates.


I don't want to give the impression that change artists are rushing around an organization inflicting help on everyone. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone.

For instance, there's a Vietnamese proverb that says, "While it is notable to assist a stricken elephant in rising, it is foolhardy to catch one that is falling down." Change artists need to learn how to recognize whether a person or department is willing to help themselves rise.
For instance, change artists should have lots of potentially transforming ideas on hand. Most of these ideas are on the process level—that is, processes for finding ideas. Such processes might include

• reaching out to other organizations, departments, professional societies, libraries, consultants, or classes
• facilitating brainstorming processes
• keeping an inventory of sample problems, toy exercises, and simulations for right-brain exploration and left-brain investigations
• conducting focus groups, and knowing how to recognize when the group lacks the necessary knowledge (A lens doesn't focus anything if there's no ray of light.)
• changing the mixture of people to obtain more diversity and knowledge
• combining ideas from several sources to produce new ideas

A good example of combining of ideas is the process of connecting what the individuals want with what the organization or the change artist wants. If the change artist thinks the elephant might be falling down, she might make her presence (what they want) conditional on their participation (what she wants). Or if management wants the group to take a risk, the change artist might negotiate some kind of insurance to give the group safety, such as extra time in the schedule, relaxed specifications, suspension of the usual measurements, or a guarantee of their old jobs back if the project flops.

Here's an example of this kind of negotiation. In an organization producing electronic equipment with embedded software, top management threw in a foreign element by mandating certain process improvements. Some of the more traditional managers were highly technical engineers, and claimed that the other managers, being service engineers, weren't sufficiently technical to do process improvement. Thelma, a change artist, was supposed to facilitate the entire group of managers working on the improvements, but she faced a problem: Who should have the job, given that the technical managers weren't doing it, and the service managers wanted to do it?

Thelma applied several change artist principles:

• Always find the energy for change and go with it. In this case, the service managers wanted to work on change, and the technical managers didn't.
•  Don't get hooked into negative energy. The technical managers knew dozens of reasons why these changes could not be made.
• Talk in their terms and find out what the issues really are. It turned out that the technical managers were overloaded with assignments just getting products out the door. The service managers were overloaded, too, but they felt that their overload was due to service requests arising from faulty technical processes. They were willing to invest their time to reduce their future load.
• Once you're prepared, go to the source. Having assembled all these facts, Thelma made a recommendation to upper management that the service managers be given the process improvement responsibility, and that the technical managers no longer be required to attend process improvement meetings. In return, the technical managers promised their full cooperation on an as-needed basis. Upper management was happy to accept her solidly-based recommendation.
• It's perfectly all right to do nothing for a time. Dormancy periods in seeds and hibernation in animals are adaptive strategies in an environment with fluctuating opportunities for growth. In human organizations, the Zone Theory says that it sometimes makes good sense just to lie low during periods of rapid change. Knowing that Chaos is contagious, Thelma wisely decided to leave the technical managers alone. Their time would come.

In other words, just like in artistry with a canvas, paint, and a brush, sometimes the empty spaces are the most important part of the work of art.

To perfect your change artistry, you might want to participate in this year's AYE Conference.

Are you a permission giver? Feynman was.

Read the entire article, then read Feynman's letters.

Amplify’d from www.theamericanscholar.org

Permission Givers

By William Zinsser

When Richard P. Feynman, one of the giants of 20th-century physics, was awarded the Nobel Prize in 1965, he received hundreds of congratulatory letters from friends and admirers, including one from a former student named Koichi Mano. Acknowledging the letter, Feynman asked the young scientist what he working on. Koichi sent a doleful reply, regretting that he wasn’t working on fundamental problems of science, but only on “a humble and down-to-earth type of problem.”

“Your letter made me unhappy,” Feynman wrote back, “for you seem to be truly sad. No problem is too small or too trivial if we can really do something about it. It seemed that the influence of your teacher has been to give you a false idea of what are worthwhile problems.” In his own career, Feynman pointed out, he had “worked on innumerable problems that you would call humble, but which I enjoyed and felt very good about because I sometimes could partially succeed.” He went on to describe a dozen of those experiments, some of which failed, including one on the theory of turbulence that he “spent several years on without success.” Read more at www.theamericanscholar.org

 

See this Amp at http://amplify.com/u/bwosl

How to Manage Teams Congruently

Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team.


Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis—leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.


We can see, then, why the democratic—or perhaps we should say "technocratic"—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside—not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning.


Indeed, once the team is selected and operating, the wise manager placed above it will adopt a "hands-off" policy with regard to its internal structure and structure change. When, as so often happens, team members come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right.


"You're right," said the rabbi, and the man left the house beaming. Soon, however, the man's wife appeared—even more distraught than the man had been.


"What do you mean," she insisted, "saying that my husband was right? You haven't heard my side of the story." And she proceeded to relate her side, finishing with a demand for a new judgment.


"You're right," said the rabbi, and the wife left satisfied. The rabbi's own wife, however, was not satisfied, for she had overheard both stories and both answers.


"How can you do that?" she demanded. "You told the husband that he was right and the wife that she was right. They can't both be right."


"You're right," said the rabbi.

[This little tale is adapted from my books: The Psychology of Computer Programming and Managing Teams Congruently.]

A fine article, but only a sample

I chose just one of the many fine entries on the TESTHEAD blog. Read this one, then try some of the others. Michael can write--but most of all, he can think!

Amplify’d from mkl-testhead.blogspot.com

Army of One: Pairing With an Expert One of the challenges being a lone gun tester is the fact that, often, you don’t have someone else to ask questions with. Sure you can talk to developers about issues and areas you have concerns about, but that’s not what I mean. It’s rare that time will allow a person to consistently sit down with a developer and just ask broad and open-ended questions about a product, a technique or an idea. Larger test organizations allow testers to have this opportunity. Frequently, the Army of One tester ends up doing most of their thinking or brainstorming alone… but they don’t have to. Today I had a cool experience. One of our domain knowledge experts had some time today and asked if we could set up a pair testing session, with the idea of “asking the product some questions”. The domain expert in this case is an Attorney very well versed in Immigration Law. There are a lot of layers to testing software that services the legal profession, which my company does. While I know a fair amount about Immigration and Employment Law just by virtue of repeatedly testing and looking at the challenges our products are meant to address, I will not have the same level of experience or expertise that a dedicated attorney would have. Read more at mkl-testhead.blogspot.com

 

See this Amp at http://amplify.com/u/bsxk5

It's the publishing wave of the future

Pay attention to Mr. Lankford!

Amplify’d from www.publishersweekly.com

Waiting for a Fair E-book Split - David to Goliath: Keep the Advance

By Terrill Lee Lankford

things

things

During a recent conversation about the new book, the editor once again mentioned that he also wanted to release an e-book version of my first novel, Shooters. I reminded him that I didn't want to do that until we were solidly in business together on the new work. After the call, I started thinking about the e-book aspect of the deal again, which we hadn't discussed in many months. At that time he had said e-book rights would be "highly negotiable." But I knew things had been changing rapidly on that front so I sent him an e-mail asking, "What is the current split for e-books?" His response: "The split for e-books is 75% publisher, 25% author." Me: "Do you have that backwards?" E-silence. I sent another note: "I'm serious: was this a typo? Does the publisher actually take 75%?" Him: "Yes. The publisher takes 75%." Me: "This amazes me. No amount of ‘platforming' can justify this. If that's the rate they expect me to accept, I'm going to have to pass. On both projects." Read more at www.publishersweekly.com

 

See this Amp at http://amplify.com/u/bs3ju

Who Can Alienate Readers Better?

I'm an author who's old enough to remember when the people who ran "Big Publishing" were book people—people who had some fairly decent intuition about books and the people who read them (in other words, their products and their customers). My first book was published by McGraw-Hill They were the biggest of the big, but they treated me with respect. For example, when I spotted trouble on my royalty statement, the situation was handled personally by the company president (one of the McGraws).

Four McGraw-Hill books later, the company was having some trouble over a bogus Howard Hughes biography, and turned down every new project for a year—including my latest manuscript, The Psychology of Computer Programming. I was naive enough to be shocked that a publisher might turn down a good book, so thought I must have done something wrong. After moping for a year of self-doubt, I recovered sufficiently to circulate the book to four publishers and was offered a contract by each of them. I chose Van Nostrand.

A year later, when the printed book was delivered, I went down to NYC to receive my first copy from the hand of my editor (a ritual I had practiced with McGraw-Hill). When I suggested we go to my editor's office to sit down and talk, he told me he didn't have an office—because he had just been fired.

Turns out he'd been fired by the corporate executives for publishing my book. In the interval since contract signing, Van Nostrand had been purchased by Litton Industries, along with (as I recall) four other publishers. The idea was to convert publishing to a "proper" business model—and this was the first such acquisition/consolidation, the one that began this new era in the publishing industry.

This new model included taking editorial responsibility out of the hands of the editors (real book people) and putting it into the hands of the executives (real business people).

Apparently their business intuition told them the book wouldn't sell, but apparently that intuition didn't work. In spite of fantastic order fulfillment screw-ups (another byproduct of the acquisition/consolidation, but that's another story), The Psychology of Computer Programming outsold all other similar books in Van Nostrand's inventory. It's still selling (I got the rights back—another stupid business decision by the executives—and the book is still selling steadily after almost 40 years—over 250,000 copies in a dozen languages. (It will be out soon as an eBook.)

And, after 40 years, these business executive are still clueless about that "book business," as opposed to their "book business." If you don't believe that, watch them screwing up the eBook business in just about every imaginable way. (Nobody said they weren't creative.) For instance, here’s what MacMillan CEO John Sargent recently had to say about libraries and ebooks:

    "That is a very thorny problem”, said Sargent. In the past, getting a book from libraries has had a tremendous amount of friction. You have to go to the library, maybe the book has been checked out and you have to come back another time. If it’s a popular book, maybe it gets lent ten times, there’s a lot of wear and tear, and the library will then put in a reorder. With ebooks, you sit on your couch in your living room and go to the library website, see if the library has it, maybe you check libraries in three other states. You get the book, read it, return it and get another, all without paying a thing. “It’s like Netflix, but you don’t pay for it. How is that a good model for us?"

    "If there’s a model where the publisher gets a piece of the action every time the book is borrowed, that’s an interesting model." - from http://go-to-hellman.blogspot.com/2010/03/ebooks-in-libraries-thorny-problem-says.html

If you don't understand what's wrong with this statement, take a look at the article and comments, "Friday Alert: HarperCollins in cagematch with Macmillan to see who can alienate readers better." <http://dearauthor.com/wordpress/2011/02/25/friday-alert-harpercollins-in-cagematch-with-macmillan-to-see-who-can-alienate-readers-better/>

Or, if that's not helping, take a look at past history—for example, the reaction of the Western Union executives when the technology for voice-over-wire (telephone) became available. Or, study the music industry executives' bungling of the digital music scene.
Whichever example you choose, it's always the same pattern of response to new science or new technology: The people on top of the existing industry always try to stifle the new in order to preserve the old. They bungle, and that opens the door for all sorts of brash newcomers. Brash, that is, until they become the fat cats and play the same bungling role when the next innovation comes along—as it always does.

The only question is "Who will be the brash newcomers this time around?"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBook novels and nonfiction listed at these stores

• Barnes and Noble bookstore: http://tinyurl.com/4eudqk5

• Amazon Store: http://amazon.com/-/e/B000AP8TZ8

• Apple Store: http://apple.com

• Smashwords Store:
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Ins and Outs of Planning a Conference Program

In response to a number of reader requests, I've asked author Marilyn Meredith to give us an essay on her experience with conference planning. She graciously consented, so here it is:

Public Safety Writers Associations’ Annual Conference

Planning the program for the Public Safety Writers Associations' annual conference is probably different in some ways for planning for other writers' conferences.

The membership is made up of active and retired law enforcement officers and firefighters, people who write articles for law enforcement and other public safety publications, non-fiction writers, and mystery writers—although there are no requirements about who can attend the conference.

When I first started with the job I had to dig a little deeper to find speakers and mainly those who came concentrated on writing topics. This year we are having some speakers who will be talking about writing topics including voice, characterization, writing thrillers, and screen writing, but we also have a police psychiatrist and a county coroner. 

Some speakers have been attendees of the conference who have come to me at the conference suggesting a topic they would like to present. Others have contacted me after the conference offering their services. All of our speakers must pay for the conference just like everyone else—and there is no other compensation. 

We also have panels which are usually writing topics like editing, about creating setting, writing for trade publication and promotion. This year we'll have one on writing with a partner, and a panel of experts (forensic expert, military person, lawyer, FBI agent) telling us what TV gets wrong.

It's up to me to figure out the schedule and I like to stagger the speakers in-between the panels.

We are always on a tight time-schedule; 15 minute breaks between the 45 minute presentations, so volunteers serve as time keepers, displaying signs to notify how much time is left. Some attendees love this job.

And as for the problems that occur sometimes: Once in awhile I have to switch the program around a bit because someone couldn't make it to their slot on time, or got sick, or just didn't show up. One plus to having so many professionals gathered together, there's always someone interesting who can fill in.

For anyone interested in finding out more about this conference, go to http://www.policewriter.com

Anyone wanting to be on a panel must register before June 1 so I can finalize the program, however someone can come to the conference and pay on the day it begins.

I love this conference because of all the interesting people I've met and become friends with and are invaluable for research. Because I write about a sheriff's deputy in one series and a whole police department in another, these people have become invaluable to me.

F.M. Meredith, also known as Marilyn Meredith, is the author of nearly thirty published novels. Her latest in the Rocky Bluff P.D. crime series, from Oak Tree Press, is Angel Lost. Marilyn is a member of EPIC, Four chapters of Sisters in Crime, including the Internet chapter, Mystery Writers of America, and on the board of the Public Safety Writers of America. Visit her at http://fictionforyou.com and her blog at http://marilynmeredith.blogspot.com

Angel Lost, an E. F. Meredith Crime Novel

As plans for her perfect wedding fill her mind, Officer Stacey Wilbur is sent out to trap a flasher, the new hire realizes Rocky Bluff P.D. is not the answer to his problems, Abel Navarro's can't concentrate on the job because of worry about his mother, Officer Gordon Butler has his usual upsets, the sudden appearance of an angel in the window of a furniture store captures everyone's imagination and causes problems for RBPD, and then the worst possible happens—will Stacey and Doug's wedding take place?

Authors You May Not Know–Yet

The writing business is one of the most difficult to break into. (into which to break?) Excellent writing and story-telling are not sufficient to publicize your name and what you can do. I do my primary publicizing through my website:

http://www.geraldmweinberg.com

and through various book retailers such as Amazon, Barnes and Noble, and Smashwords.

I also belong to a number of groups of aspiring writers, including one called Backlist Books. One of the ways we spread the word about ourselves is to exchange links to our blogs and/or websites. Below, I've placed a list of some of the backlist authors I like. There's a wide variety of genres, so take a look at them and see if there's anything to your taste. You'll be glad you did.


Doranna Durgin, http://doranna.net/wordplay

Marsha Canham, http://marshacanham.wordpress.com

Jacqueline Lichtenberg, http://aliendjinnromances.blogspot.com

Jeffrey A. Carver, http://starrigger.blogspot.com/

Jill Metcalf, http://jillmetcalf.wordpress.com

Terry Odell, http://terryodell.blogspot.com

Maryann Miller, http://its-not-all-gravy.blogspot.com/

Patricia Rice, http://patriciarice.blogspot.com

Pati Nagle, http://patinagle.livejournal.com/

Lorraine Bartlett or Lorna Barrett, http://www.LornaBarrett.blogspot.com

Karen Ranney, http://karenranney.wordpress.com

No More Reviews—With Exceptions

My call for reviewers has been so successful, I'm flooded with requests for free books.

For the moment, I'd like to suspend the reviewing (until next time) with the exception of readers who are willing to review some of my novels—which are under-reviewed.

So, if you want to review one of my novels, let me know. If you're interested in one of the non-fiction, you'll have to buy it (the e-book versions are very inexpensive) or wait until the next free book offer.

For the novels, you can see them and sample them at

http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg

And thanks to everyone who has responded.

Free books! Looking for a Few More Book Reviewers

This post is about marketing. As you probably know, I'm in the business of writing books, as part of my consulting business (or vice versa). In the modern publishing world, with more and more books bought online, customer reviews really can help books reach their full potential. Although we work with professional reviewers as well, you don’t need to be a professional reviewer to review books for me. Any avid reader can do it!

Right now, I'm looking for a few more people to help spread the word about my books. If you’re interested, please email me at hardpretzel (at) earthlink.net with the words “Book Reviewer” in the subject line.

I’ll email you back with a password that will give you access to one of my titles in Kindle, PDF, and ePub format, for your computer or your reading device.

Here’s my current titles, with more on the way:

http://www.geraldmweinberg.com

All I ask is that you review whatever book you download on either Amazon or Smashwords or Barnes and Noble’s website (or all three—that’s even better). If you’re a professional reviewer, it’s great if you review it on your blog or website, and I’ll often link to it from my own site, but I still ask that you post your review to at least one of the three just mentioned.

It’s easy to do, and you don’t even need to use your real name if you like. Five or six sentences is fine, though you can certainly write more if you wish. Have fun! And if you’re not sure how to do it, just read some examples.

Please note: It would be unethical to require you to do a positive review; all I ask is that you’re fair, and that if it’s just not your kind of book (remember, everyone has different tastes), that you just pass on doing the review at all. In the modern book selling world, these reviews have become critically important to helping books reach their full potential. Keep this in mind when you’re reviewing and you’ll be just fine: I’ve staked many hours on my novels and nonfiction.

I can give away only so many free books, so I’ve limited this round of book reviewers. If interested, please email us ASAP.*

(Thanks for this idea to Scott at Flying Raven Press, http://flyingravenpress.com/. Why not give them a visit.)

The Myth of Writers Block (and what to do when you're blocked)

Writing is one of the most important activities for successful consultants. Writing helps you capture and clarify your ideas. Writing helps you polish your presentations to clients. And published writing is probably the second most effective marketing tools in your kit. (First, of course, is recommendations from satisfied clients.)

Yet most consultants never publish an article. Of those who do publish an article, most write only one. Many consultants never publish a report. Of those who do publish a report, most write only one. And certainly, most consultants never publish a book. Of those who do publish a book, most publish only one. If you ask them why they don't write more, they will commonly say they are stuck, or "blocked." But these words are merely labels. They explain nothing. Most often consultants stop writing because they do not understand the essential randomness involved in the creative process.

The Structure of Creation versus the Structure of Presentation

Please don't get the impression that I read in the random way I write (my "Fieldstone Method." Reading, by its nature, is more or less linear, like a string of beads, and I tend to read most works through from beginning to end. But written works can be created by superimposing any of a variety of organizations on that linear string of words. For instance, novels, being stories, are more or less linear; but novelists may use flashbacks, stories-within-stories, or parallel stories to break the linearity.

Dictionaries, encyclopedias, and reference manuals—though consisting of a bound sequence of pages—are generally organized for a random access by the addition of tables of contents and indices. Internets and intranets allow us to hyperlink written works in much more complex structures, though in order to use them, we frequently need aids such as index pages and search engines.

But none of these reading organizations have much of anything to do with the organization of the creative process by which the works came into existence. These reading structures are presentation methods, not creation methods. Creation doesn't work in any such regular way. It's more accurately modeled by the Fieldstone Method. Every day is different; every idea is different; every mood is different; so why should every project be the same?

Writer's Block and the Goldilocks Questions

"Of course every day is different," you may say. "Some days I'm entirely paralyzed by writer's block, and I don't accomplish anything at all."

If this is your problem, I can help, as I've helped many other consultants and professional and amateur writers. I didn't always understand how I was helping, until one student wrote the following:

As evidenced in some conversations with other students of yours and in my own writings, I think there are number of intangibles that you do offer—in much the same way that a coach or therapist does. These include motivation, raising self-esteem, building confidence in writing, considering self-other-context, discipline, thinking more clearly, or awareness, to name only a few.

Writer's block is not a disorder of you, the person attempting to write. It's a deficiency of your writing methods—the mythology you've swallowed about how works get written—what my sometime co-author, Tom Gilb, calls your "mythodology." Fieldstone writers, freed of this mythodology, simply do not experience "writer's block." Have you ever heard anyone speak of “mason's block”? (But, yes, I have heard people talking about "consultant's block"—and what I'm saying here actually applies to much of the work consultants do, or try to do when they get "stuck.")

Many writing methods and books assume that writer's block results from a shortage of ideas. Others assume the opposite—that writers become blocked when they have a surplus of ideas and can't figure out what to do with all of them. But it's not the number of ideas that blocks you, it's your reaction to the number of ideas.

Here's how it goes. You have the wrong number of ideas, and that bothers you, causes you discomfort, or even pain. To lessen the pain, you turn to some other activity—coffee, beer, sex, movies, books, sleep, or name your poison. This diversion relieves the pain in the short run, but eventually your mind turns back to that unfinished piece of writing (or other work). Now you feel worse because you've avoided the task. You might try writing again, but your mind keeps returning to what a bad, blocked writer you are. So, eventually, you turn to your relief—coffee, beer, sex, or whatever.

Do you recognize the addiction cycle? (This dynamic is described more fully in my soon-to-be released Volume 5, Managing Yourself and Others, of my e-Series, Quality Software.) The Fieldstone method allows you to break this cycle in exactly the same way you break any addiction, by using your intelligence and creativity. I sometimes begin to feel "blocked," but when I do, I simply ask myself what I call the Goldilocks Questions:

"What state am I in now? Do I have too many ideas? Do I have too few? Or, like Baby Bear's porridge, is it just right?"

If I have too many ideas, I begin some organizing activities, like sorting ideas into different piles. If I have too few ideas, I concentrate on gathering more. Usually, the first place I look is in my own mind, staying in the flow of the moment, one idea building on the next.

For instance, when I’m writing dialogue, I don’t stop to search externally for just the right conversational “stone.” That approach leads to overly clever dialogue, rather than the more natural-sounding stones that just pop out of my head from millions of past conversations I’ve heard or overheard. Only if my natural mental flow fails me do I start searching for an external "fieldstone" to trigger a new flow.

Then, when the number of ideas is "just right," I organize them, trimming and polishing a bit in the process, until I have a finished product—or until I have to ask the Goldilocks Questions again. Sure, I may be stuck for a few moments, but I'm never "blocked."

In my book, Weinberg on Writing, I sketch all three parts of the Fieldstone Method—first the gathering of ideas (stones), then the organizing, then the trimming and polishing. The book describes them in that order, not because I perform them in that order, but because it's a book, and books are linear organizations of ideas.

Unlike what your schools taught you about writing, the Fieldstone Method is not dependent on any particular order of doing things. Instead, Fieldstoning is about always doing something that's advancing your projects. As a Fieldstone writer, you will have a variety of keep-moving activities, a handy list of tasks of all sizes, plus the knowledge to match each task to your mood, your start/stop time, your resources, and your total available time. As a Fieldstone consultant, you will have a second handy list of keep-moving activities—a list with your writing list as one of its sublists.

Each Fieldstone writer also has to find her own “magic” tasks, not all of which may seem “logical” to other writers. Meditation works for me, but others find it disturbing. Aikido boosts me, but it tires others. Some writers say you have to have a cat, a cigarette, and a cup of coffee laced with brandy.
The cigarette and brandied coffee would kill me, which would be merciful because then I wouldn’t have to watch the Lovey and Caro tear apart the cat.

Observing Your Activities

In order to be a non-blockable writer (or consultant), you need to do a bit of observation of yourself. Here's what I suggest you try:

1. Choose a day or several hours that you plan to devote to writing.

2. In your journal (all professional consultants keep a journal) record the start-stop time of different activities.

3. Record your feelings at the beginning and end of each activity. Don't interrupt your flow, but just capture a word or two.

4. At the end of the day, look at what you wrote in your journal. Do you see an addiction cycle?

5. How did you respond any time you were temporarily stuck?

6. What other activities could you have done that would have served you better?

7. How will you remind yourself of those activities when you repeat this observation exercise in a month or so?

(This article is adapted from Weinberg on Writing: The Fieldstone Method )

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Find my eBooks sampled free, and offered for sale at these stores

• My Barnes and Noble page

• My Amazon Page

• Apple Store

• My Smashwords Page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Universal Pattern of Huge Software Losses

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 Responding to Significant Software Events, I give five examples that should convince you.

The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.

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. A slight error in one constant was multiplied by millions of customers, adding 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.

I know of the next case through the public press, so I can tell you that it's about the New York State Lottery. 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. A tiny error caused duplicate tickets to be printed, and public confidence in the lottery plunged with a total loss of revenue estimated between $44 million and $55 million.

I know the next 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. 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.

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.

The Pattern of Large Failures
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.

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. [not]

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 be unworthy of observing.

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 my 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)"?

(Adapted from Responding to Significant Software Events )
http://www.smashwords.com/books/view/35783