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

Resolution #2 for the new year

Not just by writing, do more to help humanize computer business–a long way to go: <http://www.smashwords.com/profile/view/JerryWeinberg>

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

Resolution #1 for the new year

New Year Resolution #1: Make all my writings available in all eBook formats, so I'm free to write some more novels, stories & non-fiction. <http://www.smashwords.com/profile/view/JerryWeinberg>

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

n Gratitude of Gratefulness

Amplify’d from www.tommyangelo.com

6 Comments In Gratitude of Gratefulness Posted by: Tommy Angelo on December 24th, 2010

“Finish your food! Think of the starving children in China!”

That was a typical thing for parents like mine to say to kids like me as I poked at the mucoid vegetables on my plate.

“Think of the starving children in China.”

That saying failed utterly at its purpose. All it did was make me resent the alleged starving Chinese children as much as I resented being forced to eat snot. And the resentment was just getting warmed up. For the next few decades, when someone said something about how I should be grateful or thankful or whatever, I resented them for even suggesting such a thing. First, I always had lots of problems: work problems, money problems, car problems, friend problems, lover (or lack of lover) problems, etc. I kept track of and organized my problems. You want me to be thankful? Have you seen my list of problems lately? Read more at www.tommyangelo.com

 

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

The Parable of the Ones

This little essay on the consequences of choosing the wrong measurements is taken from my book, How to Observe Software Systems

One way to avoid missing important observations is to observe everything. This strategy is neither humanly possible nor economically feasible. Resources devoted to observing one thing detract from the resources available to observe other things. Perhaps that's why some Routine managers are so fond of huge "metrics" programs—as a distraction from the things they really should be observing, but don't know how to observe without being overwhelmed.

Consider the Parable of the Ones:

Merlin the Manager was tired of being chastised by his boss, Wanda, for low programmer productivity. "How can I show you that the programmers are doing something," he asked her, "when all they're ultimately producing is ones and zeros."

"I'm not interested in zeros," Wanda complained. "Zeros are nothing. How many ones are they producing?"

"Um, I don't know," Merlin stammered.

"Well, you're their manager," Wanda accused. "You should know."

"Of course," Merlin apologized, backing out of Wanda's office. "I'll institute a metrics program."

Merlin then hired some measurement consultants who showed him how to count the ones automatically in every object program, plotting them by project and programmer. The initial report showed an overall productivity of 43.78% ones, and Merlin called a meeting of all the programmers to chastise them about their low productivity.

"Look at this figure," he accused. "This means that 56.22% of all bits on memory are essentially unused—filled with zeros. Why, when I was a programmer, I could generate programs at random that were 50% ones. If this keeps up, there won't be any performance awards this year, I can assure you."

Two months later, just before the performance awards were decided, Merlin looked at his metric report and was delighted to discover that the overall productivity figure was 53.04% ones. He showed this report to Wanda, who gave him a big bonus. "Well," he thought, "that certainly shows the value of a measurement program. Now, as soon as I fire those two programmers with less than 45% ones, productivity will show another boost."

Merlin, of course, was merely illustrating DeMarco's principle. If he rewards programmers for ones, he'll get ones. Even without explicit rewards and punishments, the mere fact of observing something implicitly reinforces it. Workers always notice what their managers notice—and what they fail to notice.

As often happens, Merlin's "measurement" system has produced a backwards effect from what the organization really wants (see diagram of effects on left). If he interprets the production of zeros as wasted effort, he encourages programmers to put effort into producing ones, which really is wasted effort. Much of the effort that might have gone into correct, well-performing software has gone instead into beating the measurement system.

Testing Without Testing

The job of software testing, we know, is to provide information about the quality of a product. Many people, however, believe that the only way to get such information is to execute the software on computers, or at least review code. But such a belief is extremely limiting. Why? Because there's always lots of other information about product quality just lying around for the taking - if it were only recognized as relevant information.



Because of their psychological distance from the problems, external consultants are often able to see information that escapes the eyes and ears of their clients. Dani (Jerry's wife) tells this story about one of her consulting triumphs in the dog world:



======================================================



A woman with a Sheltie puppy was at her wits' end because "he always poops on the living room rug." She loved the little guy, so before giving up and taking him to the Humane Society, she came to Dani for a consultation. Dani listened to the woman describe the problem, then asked, "Are there any other behavior problems you've noticed?"



The woman thought about that for a while, then said, "Well, yes, there is one. He has this annoying habit of scratching on the front door and whining."



======================================================



It's easy to laugh at this woman's inability to see the connection between the two "problems," but that sort of blindness is typical of people who are too close, too emotionally involved, with a situation. Learning to recognize such free information is one of the secrets of successful testing. Using it, you can learn quickly about the quality of an organization's products or the quality of their information obtained from machine testing.

Here are some "Sheltie stories" from our consulting practices. Test yourself by seeing what information you can derive from them about the quality of a product or the quality of the information that's been obtained about the product through testing:



======================================================



1. Jerry is asked to help an organization assess its development processes, including testing. Jerry asks the test manager, "Do you use specs to test against?"



Test manager replies, "Yes, we certainly do."



Jerry: "May I see them?"



Test manager: "Sure, but we don’t know where they are."



======================================================



2. Jerry is called in to help a product development organization's testing group. He learns that they are testing a product that has about 40,000 lines of code.



"The problem," says the test manager, "is with our bug database."



"What's wrong with it," Jerry asks. "Is it buggy?"



"No, it's very reliable, but once it holds more than about 14,000 bug reports, its performance starts to degrade very rapidly. We need you to show us how to improve the performance so we can handle more bug reports."



======================================================



3. Bunny is asked to help improve the testing of a large product that has 22 components. The client identifies "the worst three components" by the high number of bugs found per line of code. Bunny asks which are the best components and is given the very low bugs per line of code figures for each.



She then examines the configuration management logs and discovers that for each of these three "best" components, more than 70 per cent of their code has not yet successfully been checked in for a build.



======================================================



4. Trudy is invited to help a development manager evaluate his testing department's work. She starts by looking at the reports he receives on the number and severity of bugs found each week. The reports are signed by the test manager, but Trudy notices that the severity counts have been whited out and written over.

"Those are corrections by the product development manager," the development manager explains. "Sometimes the testers don't assign the proper severity, so the development manager corrects them."



Using her fingernail, Trudy scratches off the whiteout. Under each highest severity count is a higher printed number. Under each lowest severity count is a lower printed number.



======================================================



5. Jerry is watching a tester running tests on one component of a software product. As the tester is navigating to the target component, Jerry notices an error in one of the menus. The tester curses and navigates around the error by using a direct branch.



Jerry compliments the tester on his ingenuity and resourcefulness, then asks how the error will be documented. "Oh, I don't have to document it," the tester says. "It's not in my component."



======================================================


6. Fanny watched one tester spend the better part of several hours testing the scroll bars on a web-based enterprise system. The scroll bars were, of course, part of web browser, not the system being tested.



======================================================



7. Jerry asked a development manager if the developers on her project unit tested their code.

"Absolutely," she said. "We unit test almost all the code."



"Almost?" Jerry asked. "Which code don't you unit test?"



"Oh, some of the code is late, so of course we don't have time to unit test that or we'd have to delay the start of systems test."



======================================================



8. One of Christine's clients conducted an all-day Saturday BugFest, where developers were rewarded with cash for finding bugs in their latest release candidate. They found 282 bugs, which convinced them they were “close to shipping.”



They were so happy with the result that they did it again. This time, they found 343 new bugs - which convinced them they were “on the verge” of shipping.



======================================================



9. A general manager was on the carpet because a recently shipped product was proving terribly buggy in the hands of customers. Jerry asked him why he allowed the product to ship, and he said, "Because our tests proved that it was correct."



======================================================



10. Another manager claimed to Noreen that he knew that their product was ready to ship because "we've run 600,000 test cases and nothing crashed the system."



======================================================



11. When Jerry asked about performance testing, one of his clients said, "We've already done that."



"Really?" said Jerry. "What exactly have you done?"



"We ran the system with one user, and the response time was about ten milliseconds. Then we ran it with two users and the response time was twenty milliseconds. With three users, it was thirty milliseconds."



"Interesting, Jerry responded. "But the system is supposed to support at least a hundred simultaneous users. So what response time did you get when it was fully loaded?"



"Oh, that test would have been too hard to set up, and anyway, it's not necessary. Obviously, the response time would be one second - ten milliseconds per user times one-hundred users."



======================================================



12. Jerry's client calls an emergency meeting to find out "why testing is holding up our product shipment." In the meeting, the testers present 15 failed tests that show that the product did not even build correctly, so it couldn't be tested. They discuss each of the 15 problems with the developers, after which the development lead writes and email summary of the meeting reporting that there are only two "significant" problems.



The email goes to the development manager, the marketing manager, and all the developers who attended the meeting. None of the testers present are included in the cc-list, so none of them even know that the email was sent.



======================================================



13. Johnson watches a tester uncover five bugs in a component, but instead of logging the bugs in the bug database, the tester goes directly to the developer of the component and reports them orally. Johnson asks why the tester didn't record the bugs, and he replies, "If I do that, she (the developer) screams at me because it makes her look bad."



======================================================



14. Tim reviews a client's test plan and notices that there is no plan to test one of the components. When he asks the test manager (who is new to the company) why it's missing, he's told, "We don't need to worry about that. The development manager assures me that this developer is very careful and conscientious."



======================================================



So, were you able to extract meta-information from these ten examples? What did each of them tell you (or hint to you) about the quality of the information from testing - the accuracy, relevance, clarity, and comprehensiveness?

Remember, though, that these are merely hints. Perhaps the Sheltie pooped on the rug because he had some medical problem that would need a veterinarian's help.

Perhaps there's a non-obvious explanation behind each of these Sheltie Situations, too, so you always have to follow-up on the hints they provide to validate your intuition or find another interpretation. And, even if your intuition is right on target, you probably won't have an easy time convincing others that you're correct, so you will have to gather other evidence, or other allies, to influence the people who can influence the situation.



When Dani asked the Sheltie's owner why she thought the pup was whining at the front door, the woman said, "I think I've spoiled him. He just wants to go out and play all the time, but I have too much housework to do - especially since I spend so much time cleaning up the mess on the rug."



When a problem persists in spite of how obvious the solution is to you, you aren't going to be able to convince others to solve the problem until you find out how they are rationalizing away the evidence that's so apparent to you. So we need to know how people immunize themselves against information, and what we can do about it.

(Adapted from Perfect Software: and Other Illusions about Testing)
http://www.smashwords.com/books/view/25400

Twitter 101

If you're new to Twitter, or intimidated by it, start here.

Amplify’d from www.yorkwriters.com

Twitter 101: A Beginner’s Guide for Writers (and Other Creative People)

Twitter 101: A Beginner’s Guide for Writers (and Other Creative People) Read more at www.yorkwriters.com

 

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

Technical Debt && Collins' Stages of Decline; OR, The Exponential Point of No Return

URL:  http://www.financialagile.com/reflections/9-general/45-...

Collins model goes something like this:



* Stage 1 - Hubris Born of Success.

* Stage 2 - Undisciplined Pursuit of More.

* Stage 3 - Denial of Risk and Peril.

* Stage 4 - Grasping for Salvation (AKA Panic).

* Stage 5 - Capitulation to Irrelevance or Death.



Now, tie this to software ...

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

Sometimes Perception Is the Problem By Payson Hall

URL:  http://www.stickyminds.com/testandevaluation.asp?Functi...

Summary: High on a mountain twenty years ago, a wise man shared secrets of problem solving that have served Payson Hall ever since. In this article, Payson passes along a simple definition that offers insights into problems and potential solutions.

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

Along with The Art of War, I read this book 3-4 times a year.

http://www.scribd.com/doc/42712109/Secrets-of-Consulting-a-Gui...

Why? Because I keep falling back to the silly state I was in before I first read them.

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

Review of First Stringers, from LibraryThing.com Weinberg has produced a delightful book that kept building both in story and in character development as you progressed. The processes of ferreting out the puzzle pieces with the characters as the adventure took them out of their comfort zones is exhilarating, and just when you think you see the outline of the picture the author brings in new characters and information to make you start all over again. Adventure. Mystery. And something … unusual. http://amplify.com/u/f7ur

The Sauerkraut Syndrome

There are quite a few consultants in the over-40 category, and that they tend to be well paid. In this post, I want to speak to some of my older compatriots about what their role is, other than just banking those big bucks. And then I’ll conclude with a few words to my younger colleagues about how to deal with us old fogies.

One thing that we old folks can do is tell stories that the young ‘uns can’t match—about such things as paper tape, relays, mercury delay lines, and sauerkraut. Sauerkraut?

Well, it’s this way. Back in the Summer of ‘49, I was on the picnic/softball circuit in Omaha, and during a game against the Tigers, I ate some sauerkraut in the bottom of the fourth inning. In the bottom of the eighth, I stretched a single into a double, sliding head first into second base—and throwing up all over the second base bag.

It was a summer to remember. The good part was that we beat the Tigers three times and won the championship. The bad? I had sauerkraut twice more and threw up both times—once behind the bench and once, as I gained more experience, under the bleachers.

Recently, I was telling some young software maintainers and their boss, Ted, about that Summer of ‘49, and Thurman asked, “Does sauerkraut still make you sick?”

“I don’t rightly know, young feller,” I honestly replied. “I haven’t et any in 50 years.”

“Oh,” Thurman said. “You should try some again. Maybe now it wouldn’t make you sick.”

“Could be,” I opined, “but I don’t see the benefit in trying. As I recall, I didn’t fancy sauerkraut all that much to begin with.”

I told a few more scintillating stories, and then we got back to work, trying to get a thorny maintenance bramble under control. At a certain point, Thurman suggested that Ted offer the maintenance programmers to opportunity to try what I call “worst-first” preventive maintenance. The maintainers would identify one component of the system that caused the most maintenance headaches, and it would be rewritten, to reduce maintenance problems.

Ted, who was showing small touches of gray around the temples, said, “I’ve seen that technique tried, and it didn’t work. The new component was just as buggy as the original, so the development effort was wasted. Since it was my idea, the management decided they would let me go. No, I’m not going to try that again.”

“So,” Thurman pitched in, “to you it’s like sauerkraut.”

“What do you mean,” Ted asked, a befuddled look on his wrinkled face.

“Well, Jerry tried sauerkraut a long time ago and it didn’t sit very well, so he’s never tried it again. Just like you and worst-first maintenance.”

Can you see now why we old guys hate you young whipper-snappers? Nobody likes to hear the truth about how they’ve aged and changed from innovators to arch-conservatives, victims of the Sauerkraut Syndrome, which works inside our heads like this:

“I’ve tried that before and gotten punished. The potential payoff for me in trying again isn’t big enough compared with the possibilities for punishment. So, I’m not going to try it again.”

The Sauerkraut Syndrome is a perfectly reasonable attitude for the older contractor. What’s not reasonable is for us old geezers to stand in the way of younger people who want to try something different. For one thing, some things do change in fifty years, or twenty, or even two. For another, the payoffs are different. Thurman has a long career ahead of him—a lot of time to recover—and a great need to get some experiences under his belt.

So, you ask, what are we old folks supposed to do when one of our younger colleagues comes up with ideas they think are new, but we’ve tried before and regurgitated? How do we break the Sauerkraut Syndrome? Here are some suggestions:

- We can keep our mouths sealed against the temptation to say, “That’s not new. I tried that back in the Depression.”

- We can keep out of the way, letting them learn from their own mistakes, or their own triumphs. For learning, nothing beats doing it your own way so you have nobody to blame if your idea doesn’t work out.

- We can be emotionally supportive. In case you’ve forgotten, youth is a highly volatile time, and sometimes it helps to have someone around who lets you know that the world isn’t about to end, regardless of how it seems.

- We can refrain from saying “I told you so” if the idea fails this time. This doesn’t help anybody, and it doesn’t make friends.

- We can admit our fears and suggest slight modifications to the idea that will help reduce them or increase our own payoff. Ted might have said to Thurman, “I’d like to try that, but we all know that the worst component right now is also the most critical, and I’m afraid that modifying it will make it worse. How about testing your idea first with a component that’s not quite so critical, to show that we really know how to rewrite a component and actually improve it? Maybe we can try that Scrum business you're always bleating about.”

- We can refrain from giving advice, especially if it’s not asked for. Advice can undermine the confidence of the receiver—if it works, it can make the receiver feel inadequate for not knowing without advice; if it fails, it can make the receiver feel stupid for listening to you. If you must give advice, give it to your fellow old folks, the way I’m doing now.

- We can move in and grasp the young colleague’s new idea if it starts to work. Ideas need time to work out their glitches, and there’s nothing quite like an older, supposedly wiser, person saying, “Oh, now I see what you’re doing. Cool!”

As for you young folks, if you’ve gotten this far, you can return our support by being a little forgiving when we forget your name, or our own telephone number, or seem frightened by your perfectly innocent and reasonable idea.

And, you can politely ignore us if we offer a little unsolicited advice that you don’t care to hear.

And, finally, you can remember this advice that was once given to me by someone even older than I am:

When an old engineer tells you something is possible, believe it.

When an old engineer tells you something is impossible, disregard it.

p.s. If you'd like to learn more about inventions and how old and young engineers kick them around, take a look at the first couple of books in my Aremac series of novels. They can be purchased as eBooks for only $4..99 each, The Aremac Project and Aremac Power. You can even get one for free (Jigglers) at http://www.smashwords.com/books/view/22171. Or, buy the paperback versions on Amazon.com or other retailers.

A Code of Work Rules for Consultants

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

The Fundamental Regulator Paradox

Read all four articles, but esp. these and the following paragraphs:

Amplify’d from www.developsense.com

Blog: Project Estimation and Black Swans (Part 4)

So: we can’t predict the unpredictable. There is a viable alternative, though: we can expect the unpredictable, anticipate it to some degree, manage it as best we can, and learn from the experience. Embracing the unpredictable reminds me of the The Fundamental Regulator Paradox, from Jerry and Dani Weinberg’s General Principles of System Design which I’ve referred to before:

The task of a regulator is to eliminate variation, but this variation is the ultimate source of information about the quality of its work. Therefore, the better job a regulator does, the less information it gets about how to improve.

This suggests to me that, at least to a certain degree, we shouldn’t make our estimates too precise, our commitments too rigid, our processes too strict, our roles too closed, and our vision of the future too clear. When we do that, we reduce the flow of information coming in from outside the system, and that means that the system doesn’t develop an important quality: adaptability. Read more at www.developsense.com

 

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

Mnemonics

How do you remember things?

I remember pi with a little poem I created some forty years ago:

C over D

Yes. I have a trick, sequences to recall,
Using one plain mnemonic faultless ordinal,
Breaching all of the barriers that retain pi–
Bereft, will all lax thinkers die,
By circles overborne?

(Pi to 30 digits, with the decimal point and a question mark at the end signifying there's more to come.)

So, how do you remember things?

Give us a comment, so we can improve our memories, too.


Or would you like a machine that replays movies of your memories?

The Aremac does that: Read:
The Aremac Project in Paperback
The Aremac Project as eBook



A Workshop to Remember

And remember, the Problem-Solving Leadership Workshop (PSL) is coming in May, and fills up fast. So tie a string around your finger, or visit my website

Rumors of My Quitting Are Grossly Exaggerated

InfoQ's website ran an essay that said:

"Now he doesn't do that much in software anymore, he writes science fiction [and] he runs his AYE Conference, which is a human potential kind of conference."

I tried to reply, but their reply function crashed on me, so I'm putting my response here, to clear things up:

Gee fellas and gals,
Well, I was slowed down for a year while beating "incurable" cancer. bit how many of the rest of you have published even one book on software in the past two years? (I've done several.)

If that isn't "much," then how about my Problem-Solving Leadership Workshop (PSL), or my keynotes at software conferences? And AYE is principally for software folks, just like your website. Isn't your website "doing much"? (I think it is.

And, then there's consulting. Don't my clients think they're doing software?

Maybe my novels are confusing you (and others). They're entertaining stories, to be sure (at least I think so, but see for yourself). But they are full of s/w lessons--just another one of the ways I'm trying to get these lessons across. You know as well as I how hard that is. So, after 50 years, I decided to try something new--in ADDITION to my other activities--books, essays, blogs, workshops, conferences, consulting--AND responding to other people's blogs, like right now.

Thanks for listening. - Jerry Weinberg

Visit my website if you'd like to know more about what I've been doing.

Have S/W Projects Hit a Wall?

I recently received an interesting set of questions about software projects from a French science journalist. I thought my readers would like to see those questions and my answers, so here goes:

Q: Do large software projects fail at a rate significantly higher than other engineering projects in physical world (also quite complex!)

A: Well, as far as total failure, yes, I think s/w projects fail totally more than, say, building ships.

OTOH, the US Navy reported a few years ago that every ship built since World War II has been late and over budget, so that type of "failure" is 100%, even though we've been building ships for hundreds of years. The Wasa (or Vasa) Ship in Sweden is a good historical example of one reason for failure: the piling on of requirements until complexity is too great.

See http://en.wikipedia.org/wiki/Vasa_(ship)

Q: Do we know exactly why ? Is it a management problem or theoretical problem ?

All the failures I have studied have been management failures. In some cases, the theory might have been wrong, but management failed to notice the signs of impending failure, or noticed them but failed to act in time to prevent the project from becoming a death march.

Q: Have we reached now a critical size of dependable verifiable code, something like a "wall of complexity" ?

A: Such a wall definitely exists, though its thickness is somewhat fuzzy. Some well-managed projects can surpass the "wall" that stops poorly managed projects. But eventually, at any given state of the art, there will be a "wall," and as the project approaches its particular wall, progress becomes sluggish and expensive. When that happens, good managers recognize what's happening and take action--generally pulling back on some of the excess "requirements."

Q: Does it mean that "Internet of things", or other big things "real time" (like FAA air traffic) we would like to build with high reliability, are not really possible for the moment?

I first worked with the FAA in the late 1950s, trying to help them build the air traffic control system of their dreams. It wasn't possible then to implement their dreams, and it's still not possible. Why? One reason is that their dreams keep growing faster than our ability to implement them. They could build a better system, but when they try to build "the best system for all time," they collapse like the Wasa Ship.

Q: Is there a lack of a theory of building large-scale software (like rules governing civil engineering in physical world) ? Is it because computer science is still a relatively young science ?

A: There is a total lack of theory, but there are some empirical principles gained from experience. I've tried to catalog these principles in my Quality Software Management series (see below).

The trouble with computer science is that it's not a science, but generally a kind of mathematics without connection with the empirical world.

Rules governing civil engineering come largely from real-world experience, followed up by some scientific work in a few areas, like the properties of building materials. In computing, much of what we do know is simply not know to most developers, who are too busy trying to salvage poorly managed projects.

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

So, how do my answers compare with yours. Am I feeling too pessimistic, or optimistic?

Why Do You Charge So Much?

Randolph's Tough Question

Randolph is one of the sharpest technical consultants in my network. Until yesterday, I'd have bet a hundred bucks that no client could stump him with a question - but I'd have lost.

When Randolph called for a bit of meta-consulting, he was so nonplussed I had to spend three whole minutes in idle chitchat, which wasn't Randolph's usual no-nonsense style. Finally, I couldn't stand the suspense, and I asked, "What's the matter, Randolph?" (Nobody calls him "Randy" more than once. It's Randolph all the way.)

"Why do you charge so much?" He blurted so quickly I didn't believe I'd heard him.

"Say what?"

"Why do you charge so much? That's what he asked me!"

"Who asked you?"

"My client. The new one."

"So what did you tell him?"

Pause. Sigh. Longer Pause.

"Randolph? Are you still there?"

Pause. Finally a weak voice said, "I didn't know what to tell him. That's the problem."

I recognized the problem and tried to reassure him. "Randolph, you're not the first consultant who's been stumped by that question. And you won't be the last."

"But I've got to go back there tomorrow, and I don't have an answer. I need help."

Turning the Question Around

Well, yes, Randolph did need help, and perhaps you do, too. Do you hesitate and stammer when your client asks this dreaded question? Are you ashamed to explain to your employee friends who make one-third of your hourly rate? Do you feel guilty that you make so much more than your spouse, who works much harder than you? And how do you handle yourself when the IRS asks you the same question? Well, I'm your meta-consultant, and unlike your IRS agent, I'm really here to help you.

First of all, I'm going to advise you to meet this question head-on by turning it around. Instead of emphasizing how much you're getting, emphasize how much they're getting. Many clients are unclear as to just what they get in return for your fee. This is not surprising, as your fee covers a wide range of intangibles. That's why you need to break out the various components, which I've done in simple ABC format so you can remember next time you're put to the question:

A. Attention. I suspect my clients would be astonished to discover how much time I spend thinking about them and their problems when I'm not "at work." I might be hiking in the woods, or reading a magazine, or taking a shower, and a thought comes to me about something that will help my client. For example, I was driving back from Los Alamos last week and suddenly realized that I'd spent the whole distance from Jemez Springs to Corrales working out a transition plan for a client in Ohio. I could have been enjoying the enchanting scenery - and perhaps I was. But most of my conscious mind was in Cleveland, developing the plan. Supper had to wait until I had the details in my Mac.

And that's just conscious attention. I don't know about you, but I often dream about my clients' problems, often awakening in the middle of the night with solution ideas. This happens so frequently, I keep paper and pencil handy on my headboard, where I've mounted a high-intensity lamp that won't awaken Dani when I'm scribbling away at three in the morning.

B. Barring Competition. While working with one client, I won't work with a client who competes directly with them in the area I'm working. This exclusivity sometimes reduces my opportunities for paying work, but clients may take this service for granted if I don't point it out to them.

C. Celebrity. As my reputation has grown, I've noticed that my clients are quite willing to use it to sell their product or programs within or without the company. They may not be aware that this use of my reputation creates a risk for me. If they make a mess, some of the dirt rubs off on me.

Ah, I've now run through ABC, but there are more items in this alphabet.

D. Dexterity. My clients unconsciously expect me to be on call, not only for the planned activity, but also for unexpected emergency jobs, incidental questions, idle speculation, and all sorts of administrative work such as rescheduling at their convenience. Moreover, unlike their employees, I get neither sick days nor vacation days. When I say I'll be there- and sometimes when I haven't said - I'm there. Even when I'm not there, I've implicitly or explicitly restricted my other activities so I'll be able to respond to their needs in a reasonable time.

Moreover, although I don't get sick leave, and I don't participate in their health benefits, I'm often expected to work under pressure, at odd hours, in inaccessible locations - all the while operating at top efficiency.

E. Education. Speaking of top efficiency, my clients don't pay directly for all the education I bring to the job - not just my formal education, but, for example, the thousands of hours I spend reading in related fields. I figure that in a typical year, I read the equivalent of two books a week, perhaps more. Very few of their employees devote this kind of personal time to their own development. And, when they take a seminar or attend a conference, their employer pays for them - but not for me. (Well, sometimes they do, if it's directly related to their problem and nobody else's.)

F. Flexibility. My clients can release me in a minute if they no longer need my services. Even in these days of downsizing, they don't have this cheap kind of flexibility with their employees.

G. Gratuity. Although I may charge clients for out-of-pocket costs, such as transportation and hotel rooms, I don't charge for meals, supplies, reasonable phone calls, faxes, mailing, and so forth. All these gratuitous expenses save paperwork for my clients, and they're lumped in with my other overhead - my own office space, utility bills, computers, software, network services, professional services, and the like.

H. Honesty. The work I do for my clients can sometimes literally mean the life or death of a project or campaign. This is a grave responsibility, and I accept it fully and do whatever is necessary to give full value. And, unlike an employee, I offer my clients a money-back guarantee of satisfaction with my work.

I. In-house Labor. Nowadays, most consultants/contractors are paid by the hour, or sometimes the day or week. This method of payment tends to emphasize a single tangible component of what my client is getting - my face time toiling on their premises. If they look at me as simply another grunt, grinding away in their office, no wonder it's hard for my clients to understand why my apparent rate is larger than that of their typical employee. They're missing all the other letters of the alphabet.

ZZZZZ. Sleep. Of course, I do have to sleep once in a while - and, unlike some of their employees, I'm not charging them for this. Even when I dream about them.


So there you have it, my Abecedarian cheat sheet that will prevent both you and Randolph from ever again being stumped by a client's question.

Amplify Experience

The last two times I've tried to clip an interesting web page, Amplify has failed me. Most recently: http://tinyurl.com/2f98zku So, go there yourself and have a read. http://amplify.com/u/92fe

(two days later)

Encouraged by Amplify's president, I made a few changes and tested Amplify again.

So, with a little help from president Goldstein, I now have Amplify working again. It's a fine idea.

If you don't know about the app, look up his article, "What’s the need for Amplify?"

And, after all, I'm host at the Amplify Your Effectiveness Conference (AYE Conference), so I'm all for amplification of effectiveness, which Amplify helps me do.

How to get a job or assignment

One of my colleagues recently wrote about her difficulty in landing consulting assignments. She has some great unique models, but, as she says, ...

The Problem

Most large companies (w/ no R-D labs) have the resources to take risks but refuse to.

Small companies have the guts to take the risks, but do not have the resources or the macro set of processes to do it. ...

What do you think?

Some Solution Ideas

It's one of the paradoxes of the consulting business.

Sometimes, the trick is to choose medium-sized companies. :-)

Seriously, people retain your services only when they know you enough to trust you. Consequently, my preferred method has always been to have a stepped-variety of offerings so they can start to know me in safe, tiny steps (books, keynote addresses at conferences, blogs, comments on blogs, ) ...

Then have medium steps (like workshops, tutorials at conferences, ) ...

Then larger steps (consulting visits)

Then really big steps (consulting contracts ).

Then retire rich.

Solution Ideas for Getting Hired on a Job

These days, it's not just consultants who are having a hard time finding the work they want. In the same mail, I got the following email from Liam, a recent PSL grad:

"As you were advising me to start looking for a new job in the Spring of '09 at PSL, you won't be surprised that lost my job at XYZ at the end of last year."

Not surprised, but disappointed. Still, in the long run, these changes usually work out for a much better situation. Losing the job is just confirmation of a lousy situation.

"I am still looking and would welcome any ideas or advice you might have."

The Problem of Getting Hired on a Job

Well, I just finished an email to another grad who's trying to establish his consulting business (which is getting a number of jobs, so there are many similarities). I'll quote what I told him:

Sometimes, the trick is to choose medium-sized companies.

***[Liam: this might apply to job-hunting, too. In any case, whatever you're doing now, change something--bigger, smaller, more or less medium, you know.]

My preferred method, though, has always been to have a stepped-variety of offerings so they can start to know me in

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

- Then have medium steps (like workshops, tutorials at conferences, ) ...

- Then larger steps (consulting visits)

***[Liam: interview visits, but also visits to help you show off by
doing something for them that's specialty of yours, just a talk, maybe]

- Then really big steps (consulting contracts).

***[Liam: hiring, which is a really big step these days, so perhaps hiring for a trial period, to minimize their risks]

Then retire rich.

Applying My Own Advice

Well, I'm already rich, haven't wanted a "job" for half a century, and have more consulting requests than I can handle. BUT, I'd like to be "hired" more often in my new "career"–writing fiction that entertains while teaching, or teaches while entertaining. I'm trying to apply my own advice to this new situation:

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

***[Jerry: A book is already "tiny" for your consulting business, but in the book business, that's it! Well, no it isn't, so I'm trying to make samples available (see one example below in the Appendix, my email signature, which is another tiny step) ]

- Then have medium steps (like workshops, tutorials at conferences, ) ...

***[Jerry: I offer workshops and tutorials for writers (writers are a small part of my potential audience, yet can be quite influential). I set up a book table at conferences, where people can actually put their hands on books. I've tried book-signings, but they're pretty painful when nobody shows up. And larger samples.]

- Then larger steps (consulting visits)

***[Jerry: I haven't really figured out how to do this. Well, I've just become a member of Book View Café, a writers' cooperative, where I have serialized one of my books for free, and will blog pretty regularly http://www.bookviewcafe.com]

- Then really big steps (consulting contracts).

***[Jerry: I've had some offers to write books-for-hire, but that's too much like a job. I suppose I'm fantasizing that some huge publisher will see one of my books and offer to make it into the next Harry Potter, but that's just a fantasy. And if they offer me a movie option, I'll turn it down. I used to live near Hollywood, and the smell of it was more than enough for me. (but I do love going to movies, but I saw what they did to the book of a friend of mine--and no thanks. He now wears a t-shirt that says, "Don't judge a book by its movie.")]

Then retire rich.

***[Jerry: You already did that, so take $$$ out of the equation. Write for fun, but get as many readers as you deserve, neither more nor less.]

A Cry for Help

After sending those two replies to my students, I immediately realized I had failed to mention the most important possible solution. (Isn't that what always happens when you hit the SEND button? Maybe I should sell SEND buttons to writers who need inspiration.]

What's that solution idea? Obviously:

- ask your friends for solution ideas.

So, friends, any ideas for my fiction business?

- And, oh, yes, you can ask your friends for jobs/assignments.

So, friends, I wouldn't object if you bought a book or two.

- Motivate them, or why would they want to do it.

Well, I believe my books ought to be self-motivating, but I have to motivate potential readers to actually look at them. So, perhaps because you know my non-fiction, or my teaching, you might be motivated to buy one of my books (either e-book or paperback). And, if you read it, and don't like it, I'll personally refund your money.

But if you do like it, I wouldn't object at all if you told me, and even wrote a review of it for Amazon, Smashwords, Powell's, your blog, or any other place that accepts reviews. If you do, I'll give you the free book of your choice, as a small thank you. Heck, I'll even give you your money back, if that's what you prefer.

And, yes, I really mean it.



Appendix: My Email Signature Inviting Sampling

How to sample my novels (try before you buy):

Suggestion: Go to the CreateSpace website for each of the books below and see a short description of the book.

Or, if you want a sample, click on , then click on a title you're interested in sampling, then "buy" the book and ask to see the sample.

Or, for most of the books (not fully updated yet) you can read smaller samples on my website (below).

http://www.geraldmweinberg.com/Site/eBOOKS.html



Or, if you prefer them as quality paperbacks:
First Stringers: https://www.createspace.com/3463980
Second Stringers: https://www.createspace.com/3464933
The Hands of God: https://www.createspace.com/3466119
Mistress of Molecules: https://www.createspace.com/3390916
Freshman Murders: https://www.createspace.com/3469259
The Aremac Project:
Aremac Power
Earth's Endless Effort

First Stringers: A free version

Book View Café offers you a chance to buy this exciting science fiction novel from Jerry Weinberg, absolutely free.

Amplify’d from www.bookviewcafe.com

Gerald M. Weinberg

First Stringers

In the near future, a group of handicapped twenty-one-year-olds with the ability to control the string structure of the universe, find each other and form an alliance against the people and organizations who would hunt them down and use their powers to conquer the world. As they discover one another they must strive to master their abilities, overcome their conflicts, face their personal fears and discover their deepest values in order to become more fully human.

First StrFirst Stringers

Book View Cafe is pleased to present First Stringers in free serial form.

First Stringers is also available in trade paperback and as an ebook. Read more at www.bookviewcafe.com

 

See this Amp at http://amplify.com/u/8w09

Attendance Too Regular? Try This!

Inspired by Ajay Balamurugadas's blog at

http://enjoytesting.blogspot.com/2010/08/aware-of-other-side-of-your-application.html

The title was Enjoy Testing

which starts with:

"For the past few months, I left office at sharp 6 p.m. I felt I should not invest more hours just because someone's estimate was wrong. So, I always took the 6 p.m. cab to home instead of the 8 p.m. or 10 p.m. cab."

And Michael Bolton commented:

"...I perceive that resolution to the trickiest part of the problem starts with recognizing people."

Michael is right. It starts with people. And guess who is the first person to recognize?

Yourself, of course.

The very first thing that struck me about the (quite fine) post was the regularity with which you come and go to work. Ordinarily, such regularity is a highly valued trait. For example, people can count on knowing when you'll be there and when you won't. Very good contribution to communication--and thus very high on every tester's list.

However, as an experienced tester, you already know that too regular, too predictable, behavior is a way to miss a great many bugs--and that's true of the regularity in attendance, too.

I would suggest you come in a couple of hours early on some random day next month, and (on a different day, probably) leave quite late. And, if you have people who work night shifts, arrange to be around for one or two of those.

I probably didn't have to explain why, but some of Ajay's readers may be less experienced than others. Experienced testers can probably all tell stories of when they came in early or left late (or were somewhere they weren't usually expected to be, or even prohibited to be) and because of that noticed something that led to a bug they never would have seen otherwise. (Perhaps something they were totally unaware of.)

I myself can tell many such stories, including one that may well have saved astronauts' lives, so I regularly practice being somewhat irregular in my behavior as a consultant (yes, I know that's a paradox).

AYE: The Book #AYEconf

It's been ten wonderful years, folks, and we're still at it, still filling up, still helping with careers. And lives.

Amplify’d from www.erikgfesser.com

New Book Review: "Amplifying Your Effectiveness"

New book review for Amplifying Your Effectiveness: Collected Essays, edited by Gerald M. Weinberg, James Bach, and Naomi Karten, Dorset House Publishing, 2000, reposted here:

This book is a collection of "pre-cedings" written by 17 software consultants for a conference of the same name. In the introduction, Weinberg explains the frequent ineffectiveness of proceedings typically distributed at the end of conferences. These essays (the entire text is less than 150 pages) present a preview of the hosts participating in the first "Amplifying Your Effectiveness" conference by demonstrating the diverse styles and interests of the authors. Weinberg explains that within any organization, improvements in effectiveness can occur at three levels - the individual ("the Self"), the team ("the Other"), and the organization as a whole ("the Context") - and that this collection attempts to address all three levels. In addition, there are three fundamental abilities that contribute to the effectiveness of a manager or any other technical leader: "the ability to observe what's happening and to understand the significance of your observations", "the ability to act congruently in difficult interpersonal situations, even though you may be confused, or angry, or so afraid you want to run away and hide", and "the ability to understand complex situations so you can plan a project and then observe and act so as to keep the project going according to plan, or modify the plan". These three abilities are also addressed in this collection because the least developed among them prevents one from amplifying effectiveness the most. Read more at www.erikgfesser.com

 

See this Amp at http://amplify.com/u/8q5o

Desert Island Reading List

Blogger Jon Jagger describes himself as a self employed software consultant-mentor-trainer-programmer etc specializing in agile software development (people and process), test driven development, deliberate practice, design, analysis, OO, UML, curly bracket languages (C#, C++, Java)

Jon recently published a list of 10 (+1) books he would like to have if marooned on a desert island. It's a fascinating list, and not only because it contains three of my books. You can read Jon's justification for each book at:

http://jonjagger.blogspot.com/2009/09/desert-island-books.html

But here they are. How many have you read?

* [1] Kevin Ashurst. (1977 Long out of print). World Class Match Fishing, Cassell, ISBN 0304-297291.

* [2] Phillip Pullman. (1995). The Northern Lights (The Golden Compass in USA, Knopf), Scholastic, ISBN 043995178X

* [3] Douglas Adams. (1979). The Hitch Hikers Guide to the Galaxy, Pan, ISBN 0330258648

* [4] Gerald Weinberg. (1985). The Secrets of Consulting, Dorset House, ISBN 0932633013

* [5] Gerald Weinberg. (1998). The Psychology of Computer Programming: Silver Anniversary Edition, Dorset House, ISBN 0932633420

* [6] Monty Python. (2001). The Life of Brian (screenplay), Metheun, ISBN 0413741303

* [7] Jon Bentley, (1989). Programming Pearls, Addison Wesley, ISBN 0201103311

* [8] Fred Brooks (1985 2nd edition). The Mythical Man Month, Addison Wesley, ISBN 0201835959

* [9] Peter Senge (2006 2nd edition). The Fifth Discipline, Random House, ISBN 1905211201

* [10] Gerald Weinberg (2001). Introduction to General Systems Thinking Silver anniversary edition, Dorset House, ISBN 0932633498

* [11] John Gall (2002 3rd edition). The Systems Bible: The Beginner's Guide to Systems Large and Small , General Systemantics Press, ISBN 0961825170

So, that's Jon's list. What would be on yours? Are any of Jon's choices books that you wouldn't care to have on your desert island?

p.s. Jon's going to be at AYE Conference in November, and so will I, in case you would like to discuss choosing books and other topics with us.

50 more ways to improve your business

Wolfram Arnold writes:
Here are the points I've transcribed from the meeting today. At some point I lost count as to which one was odd and which one was even and I just recorded them all (touch-typing helped :-):

---------------------
Jerry Weinberg 8/20, 50 things to improve business

2. back up everything

4. Rule: do nothing, revised with 3 caveats: a) don't do it if there's someone that can do it better; b) don't do it if there's someone that can do it adequately; c) if it makes me really happy, do it anyway; d) if someone can do it 85% as well as I do, let them do it; e) anything not worth doing is not worth doing right; f) if in doubt charge for sales trips

6. make them pay something, with their time, their money -- if they don't pay for it they don't value it

8. if it's not on paper, don't do it

9. listen to what other people are telling you

10. don't communicate to somebody, but communicate with somebody

11. always have an exit strategy

12. make them feel like your client has a part in the final outcome; make sure they have their fingerprints on it

13. listen for what they're not saying

14. listen to the "music", body language, intonation

15. always be ready to sell your product

16. if you find yourself reluctant to sell your product, there's something wrong with it

17. any successful services company has some fixed priced product to sell

18. given them entry points that they can buy

19. recurring revenue model, e.g. via contract maintenance plans, or follow-through

20. have a follow-through clause in contract so you can know how you're doing

21. charge more money if they don't want you to come back after some time, e.g. 3 months

22. if you just build it they probably won't come

23. manage expectations, book: Managing Expectations, by Naomi Karten

24. Time spent in reconnaissance is time well spent

25. You can observe a whole lot just by watching (Yogi Berra)

26. Go hard or go home; fully commit all resources needed, or kill it mercilessly

27. Commit enough to learn what you have to learn to find out whether it's worth pursuing or killing

28. People who work in an Agile/iterative way often fail to do the discovery

29. Ideas by themselves aren't as valuable as you think they are; don't guard them too closely

30. Nothing is as dangerous as an idea, esp. if it's the only idea you have

31. Never rest on your past successes; there is always something more you could be doing; if you're not learning, you're dead

32. Sharing competitive advantages brings 10-fold rewards; give it away, it comes back

33. Being able to say 'no'

34. Research clients as if you were hiring them

35. Recognize that every client is unique.

36. You don't have to remember everything to succeed.

37. It's ok to let a client go if it's not the right fit; you should organize your business such that it's ok to let a client go, i.e. don't be over-dependent on any single client

38. The best way to build a business is to stay in business; stay around, build a reputation and credibility

39. Actively solicit feedback from clients; actively extract the feedback, e.g. watch the audience

40. Don't be alone in your work; have someone to talk to

41. Honor the people who are your sounding board and bring feedback, e.g. life partners, friends, ...

42. Anything that's annoying or repetitive should be automated or stopped

43. Track your budget & cost every month

44. Don't make mistakes over your budget or your cost.

45. Don't spend your money on office decoration, esp. if your clients don't come to your office

46. Always try someone out before you hire them

47. Don't fall for the big lies: "we're just about to get funding" "our data is clean" "your check is in the mail" "we're going to sign it next month, just keep working" "don't worry about the contract" ...

48. Preventing any one of these mistakes will pay for this conference

49. Double your reading speed

50. Choose not to read a lot; don't read stuff that's not worth reading

51. Stay off Facebook & Twitter

52. Sometimes you can save money by spending money; and sometimes the reverse. Learn to tell the difference

- Thanks for the great job, Wolfram

50 Ways to Improve Your Business

At last week's BizConf, I ran a session based on an idea from Dwayne Phillips, where a bunch of independent businesspeople brainstormed 50 small ways to improve your business. The ideas flew fast and furious, so I assigned two participants, each to capture alternate ideas. Even so, it was hard to keep up with the flow. The lists were quite overwhelming, so I'll present them in two separate blogs. Today, it will be Jason Seifer's list. Jason said, "I wound up just logging everything, because I touch type like in your first rule."

So, here's Jason's list:

1. Learn to touch type.
2. Back-up everything. Every day.
3. Keep as much stuff online as possible.
4. Do nothing. Don't do something if someone can do it better. Don't do it if someone else can do it adequately. Do it anyway if it makes you happy. Don't do it if someone else can do it 85% as well as you.
5. Anything not worth doing is not worth doing right.
6. If in doubt charge for sales trips. If they're not willing to pay for it they don't value it.
7. If it's not on paper don't do it. If there's money involved it has to be written down. Never agree to money over the phone. If on phone, confirm in writing.
8. Listen to what other people are telling you. Instead of communicating to somebody, communicate with somebody.
9. Always have an exit strategy.
10. Make your client feel like they have a final part in the outcome. Make sure they have their fingerprints in it.
11. Listen to what they're not saying. Listen to body language and tone of voice.
12. Always be ready to sell your product if they're interested. And if they're not.
13. If you're bashful about your product, there's something wrong with your product.
14. Any successful services company has some fixed product that they sell. Have a ladder leading to your ultimate product. Don't make one big leap to the final product.
15. Make sure your contracts have some kind of follow-through so you can see how they actually came out. You won't know if you're doing well if they don't come back.
16. If you just build it they probably won't come. Alternately: if you build it be prepared to wait.
17. Manage expectations.
18. Time spent in recon is time well spent. But you have to be watching. "You can observe a whole lot just by watching."
19. Go hard or go home. Fully commit the resources to make something work or mercilessly kill it. You may not always know when it's time to kill it.
20. Ideas by themselves are not as valuable as you think they are. Ideas aren't worth anything so don't guard them too closely. "There's nothing as dangerous as an idea if it's the only idea you have."
21. Never rest on your past successes, there's always something more you could be doing. If you're not learning you're dead.
22. Sharing competitive advantages brings back advantages ten-fold.
23. Be able to say "No" to a potential client.
24. Research your clients as if you were doing the hiring.
25. If you're in the services business every client is unique. "We're different" "You are, just like everybody else."
26. You don't have to remember everything to succeed.
27. It's always ok to let a client go if it's not the right fit any more.You should organize your business so it's ok to let any one client go at any time.
28. The best way to build a business is to stay in business. Build your business so that you hang around. You may not make a lot of money but you build your reputation.
29. Actively solicit feedback from clients.
30. Actively extract the feedback. There's a lot of feedback you may not pick up on.
31. Make sure you're not alone in your role. This way someone can be honest with you.
32. Anything that's annoying and repetitive should be automated or stopped.
33. Track your budget/cost every month.
34. Don't make sampling mistakes about your budget and cost. One of the major mistakes that people fail at is expecting that income will stay the same. You might land a big client this month but might not have one next month so don't overspend.
35. Don't spend your money on office decorations. Very few of us are in a business where clients come to your office. You don't want your customers to think you're spending their money on their office furniture.
36. Make sure you've worked with someone before you hire them (if possible).
37. Learn the big lies you get from clients.
38. Double your reading speed.
39. Cut down on what you read.
40. Stay off facebook and twitter unless you can relate it to your business.
41. Sometimes you can save money by spending money.
42. Sometimes you can save money by not spending money.
43. Everyone who wants to sell you something will tell you it saves money.
44. The examples might not always teach what they're supposed to.
45. Many minds can do a better job than single minds. But not necessarily so.
46. You have to be organized.
47. Know your own limitations.
48. Learn quickly whether or not you want to work with someone.
49. If you see an organization with no enthusiasm for what they're doing they probably don't have enthusiasm for what you're offering.
50. If an organization doesn't care enough to organize, nothing is going to happen.
51. Don't mistake a solution idea for a problem definition.
52. People want a recipe but no recipe works for every organization.

So, that's Jason's (half) list. Each one could probably be a blog entry, at least, so if you want clarification, or to clarify, add a comment. I'll post Wolfram's (half) list when the traffic on this one dies down.