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.

The Evolution of an Exercise

(Rhonda asks Jerry for a little consultation.)

RHONDA: I'm a little nervous about my "speech" at a conference in a couple of weeks and wanted to see if you have time for some feedback.

JERRY: First feedback: If you weren't nervous, then you'd give a boring speech, guaranteed. Breathe into your nervousness and it becomes excitement.

RHONDA: It's the first time I'm presenting representing my company, the virginal gig so to speak, and I'm unsure what to prepare to make best use of the limited time while not knowing how many participants are going to join my session.

JERRY: Don't worry about "using time." Design the session so that the most important things come first (or early). That way if you "run out of time," you've covered as much as you could have.

RHONDA: "Whatever happens, happens" has been my mantra for a while already, and most of the "what-if's" won't get my blood pressure up (at least not until the hour before I go up front). To be honest, I've thought about this session for so many weeks now and feel so close to it that I feel stuck, like I have blinders on, and can't see alternative options how else to execute it.

JERRY: Stop thinking about it.

Instead of thinking, start doing. Figure out a way to practice it on some friends. Invite some of those friends over for wine and cheese or beer and pretzels or something, then use them as a surrogate audience and listen to their feedback.

RHONDA: I'm advertised thus: Starting Your Own Business - Building the Life You Want. The purpose of this presentation is to share with the audience the journey the presenter followed from international student via international employee and trailing spouse to expat coach and owner of her own company.

JERRY: Rewrite this, if only for your own use. The purpose is not to "share experiences with them." That's a means of achieving the purpose, which is something like "helping the audience members to succeed in starting their own business." IOW, more about them; less about you.

RHONDA: Rhonda draws on over 10 years of personal expatriate experience that made her want to support others. The audience will hear tips and descriptions of how and where she got the necessary information to dot the i's and cross the t's en route to realizing her dream. She will also make time for and encourage the audience to share their experiences and brainstorm ideas to make sure everybody who wants to start a business will leave her presentation motivated and informed.

Objectives I have for the "speech" (assuming participants come to hear about how to start their own businesses - is that a mistake?

JERRY: It will reduce your audience, which could be good or bad. Who else would benefit from this session?

RHONDA: Should I assume anything at all?):

   a) clarify their vision / focus their goals

   b) raise awareness of hidden obstacles

   c) identify concrete action steps to get started

Writing a business plan answers all three objectives.

(I've compiled a handbook with information about expatriate work permits, business structure comparison, business owner character traits, and useful links and resources to cover more start-up info. The handbook will be available either as print-out or .pdf file in exchange for their email address after the presentation.)

JERRY: Emphasize the handbook. People like takeaways.

Also emphasize what Eisenhower said: "The plan is nothing; the planning is everything." Maybe you could have them step through your planning process with you, each one (or team) doing their own planning steps as you go along.

RHONDA: Here are some of the parameters:

   75 minutes

   Should expect between 20 and 50 participants

   Don't know exact number

   Can't put the whole start-up process in 75 minutes

JERRY: So do selected parts, most important first.

RHONDA: I won't spend 75 minutes lecturing

JERRY: You'd better not.

RHONDA: Session Outline

   (5-10 minutes intro/warm-up)

   Exploration: 10-15 minutes to explain benefits, structure, and reasoning for a business plan
   Introduce business plan segments (e.g. client and product profile, market profile, marketing strategy, organizational structure and finances)
   Set up exercise: If I have 20 participants, I'll use one new venture/market scenario. One group per segment. Each group reads background information I provide (or would it be easier if they make up their own venture and background?) and answer business plan questions. Time: ca. 5 minutes

JERRY: Definitely better if they use their own, and you do it incrementally. You don't need to do the overview up front. You want to get them doing things more quickly than that. As it is, you have more than 1/2 hour before they do anything.

For example, pick the part of planning that's most important and start with that. When you've done that, and everyone has done that and questions are answered, move to the next most important. Do as many as you can cover properly without rushing. Then, when you see that ten minutes are left, conclude with an overview of all the segments they need to do to have a plan, and tell them about the handbook--again.

RHONDA: If I have 50 participants, I'll use two or three new venture/market scenarios, e.g. dog-wash salon in Seattle, pizzeria in Paris, recruitment office in Barcelona?

JERRY: No, too much time explaining the scenarios, which do them no good. Doing their own scenarios saves this time and ensures real interest in the exercises. If someone doesn't have one of their own, have them pair with someone who has one of their own.

RHONDA: Discovery/Application:
   Participants write a business plan for their venture. Time: ca. 20 minutes.
   Debrief/Application: In whole group, write executive summary for each venture, taking most important bits from each segment on flip chart, (take a picture, send it to them afterward with a thank-you note). Time: ca. 30 minutes.

JERRY: You can do this with lessons they learned from each different
startup, which lets them see what different startups have in common, and
what are the exceptions.

RHONDA: Question: Is 30 minutes enough debrief-time for an exercise like this and group size of 50 people?

JERRY: No. At least five days would be required to do it properly. But, you don't have that, so do what you can. If you do this incrementally, you can extract lessons after each segment, then do as many segments as
develop naturally.

RHONDA: Am I trying to cram too much in in general?

JERRY: Yes.

RHONDA: Ideas for a possible shorter exercise that would make 50 people feel involved and stimulated?

JERRY: Basically the same exercise, but chopped up and presented incrementally.

JERRY: BTW, if you really have 50, best to have them work in teams of 3-5 people, each formed around one person who has a specific startup in mind. To do this, you have individuals write signs that say, "Dog- walking business," or "Real-estate for the rich and famous," or "Coffin upholsterer," or whatever they're actually thinking of starting. Those that have signs hold them up, and people attach themselves to the ones they're interested in to make teams.

Does this help?

RHONDA: Yes!

How to Be Happy, Though in a Non-supportive Environment

Jerry: Here's another email consulting dialogue that Larry found helpful.

Larry: My name is Larry. I am a software test manager at an insurance company east of Chicago.  I have faced challenges when trying to do what I consider good testing.  These challenges include standards that mandate scripted test cases, fellow managers who don't want to discuss work, and security policies that don't allow us to quickly get tools that will aid in our testing.

A while back I discovered Cem Kaner's web page and it opened me up to a whole new world of software testing.  I learned of people like you, James Bach, Michael Bolton, and several other great thinkers.  I wonder how many people spend a career in software development/testing/ management without ever learning of these great people.

Jerry: Quite a few. To have a great career in any profession, you have to reach out and find sources such as these. You need to participate in a conference once in a while (the AYE Conference in November would be my number one choice in your situation). After that, our Problem Solving Leadership workshop would be an ideal goal to aspire to. You should certainly join your local interest groups, and participate.

Larry: This has led me to a question that I hope you can help me with.  How smart does someone have to be, to be happier when they read your books?

Jerry: Sometimes, just reading is sufficient, but most of the time, the reader has to begin doing something they weren't doing before. Like the suggestions above. Or like tackling one of the problems you cited--the standards, your fellow managers, or security policies. Or some smaller problem that nags at you.

But only ONE at a time, to learn what works for you and your organization. And what doesn't work.

(If nothing works, you want to be looking for a better place to work.)

Larry: It's almost like you know me. I think I have an NT temperament (QSM Volume 3 helped here) and based on some of the other research I've done it is definitely true that when I have a lot of tasks and become stressed I almost lock up. I rationalize that it is because I can't devote enough time to do a good job on any one thing, but I know I need to just suck it up and handle on item really well. That may go a long way to improving my happiness.

Jerry: From the little I know, I think if it were me, I'd try to find (at least) one of my fellow managers who is willing to spend some time with me discussing things that we could accomplish to improve matters for our company.

But any little thing you could move forward would be educational--even if it "fails" you can extract some learning from the attempt.

Larry: I have read five of your books so far:

* Are Your Lights On?
* Quality Software Management: Volume 1
* Quality Software Management: Volume 3
* Exploring Requirements
* Weinberg on Writing

To be honest I probably can't say "read" in the same sense that you might. I read some areas in depth and browsed others. I'm making second passes through several.

Jerry: That's exactly the way I read.

Larry: My worry is that I feel less happy after having read your books.  They have shown me how much I have to learn, and I believe that I'm not in the right environment to continue this learning.

Jerry: At least you haven't run out of things to learn. Now THAT would be really depressing.

As for the environment for learning, no environment can stop you from learning, if you really care. But, yes, you may eventually decide to keep an eye out for an opportunity in a different environment.

Larry: Each step I take towards more critical thinking, a strong thirst for knowledge, a greater understanding of how much I really don't know is a step I'm taking away from my peers at work.

Jerry: As for your peers, by taking a step ahead of them, you may well be modeling a new way for them to be happier. It's called being a "leader."

Larry: This has led to a lot of work related stress and unhappiness, and I'm more unhappy than I have been in a long time.

Jerry: In volume 4 of Quality Software Management, you'll learn about the Satir Change Model, and why significant change is usually preceded by a period of chaos, which might feel unhappy until you realize that it's a natural step on the way to happy change.

Larry: That's interesting. My personal experience says that I do tend to have phases of unhappiness, but I come out of it much stronger. It is just hard to know where I am in my journey at a specific point in time. Am I climbing up or falling down?

Now, I'm not writing to blame your great books for my unhappiness. I just have a feeling that other people have had similar journeys, and I was wondering if you've encountered a similar phenomenon. Do you have any more insights for a young unhappy software tester?

Jerry: I suspect my newest book, Perfect Software might be a good read for your manager and your fellow managers

Larry: I actually forgot about that book on my list. It is sitting on my desk pointing anyone who walks in. I'm hoping someone will pick it up and be interested, but that hasn't happened yet.

Jerry: You need to be more patient, and more aggressive, at the same time. Not easy!

Peter Principle Simulated

Some Italian professors have tried to simulate the famous Peter Principle:

"All new members in a hierarchical organization climb the hierarchy until they reach their level of maximum incompetence."

http://www.technologyreview.com/blog/arxiv/23800/

The Peter effect arises from the practice of promoting the best performer at Level N to a position at level N+1.

The Italians also simulated two other promotion policies:

1. Alternately promote first the most competent and then the least competent individuals.

2. Promote individuals at random.

According to their simulations, each of these methods improves the efficiency of an organization over the Peter method.

My thought: They could try promoting on the basis of who is most suited for the next level job. Duh!

Or maybe they could try not mixing the concept of "promotion" with that of "reward."

Or maybe even getting rid of the hierarchical notion altogether.

The Paul Principle

As a relevant post-script for my audience, they might want to look into the "Paul Principle," proposed by Paul Armer, who, like me, started out in computing as a desk calculator operator (or "computer" as we were known back then).

"People become progressively less competent for jobs they once were well equipped to handle."

Paul proposed his law in 1970, the year after Peters proposed his. Paul claimed his principle was more relevant in high-tech fields, when the complexity of jobs grows faster than the people doing them. The Paul Principle has been virtually forgotten, but I think it is still worth some careful thinking by IT managers and consultants.

The Other Paul Principle

It seems there's another "Paul Principle," after St. Paul's treatise in Corinthians:

"Continue to provide people with what they need to succeed."

I suspect this management principle would also prove more effective at growing an organization than the Peter Principle.

Perhaps those old Pauls knew something that's still worth studying today.

Why Choose One Conference Over Another?

In these days when money is short, lots of people cannot afford to participate all the conferences they might have attended last year. Money may be the first criterion for choosing conferences, but it's not the only one. I'm going to three conferences this year, each chosen by different characteristics. For me, money doesn't enter into it, so my reasons might be helpful for those who can afford to be in at least one conference, but are trying to choose. my first step in choosing a conference is to eliminate the majority of conferences by applying the following guides.

What Makes Conferences Less Attractive

I generally eliminate conferences that

- overschedule event with no time or place for spontaneous meetings

- overcrowd, usually to maximize profits, with just too many people, which encourages people to hang out only with their old pals

- lack adaptability so opportunities pass by without notice or care

- offer too much lecturing, not enough interaction, and insufficient experiential work--or none at all

- invite presenters of widely varied and untested skill and preparation

- do not name their presenters in advance, or give biographical information

- provide insufficient time and space for socializing, meeting new people

- allow little or no interaction with the presenters (In some conferences, presenters eat in a special area, intentionally separated from the participants. In others, presenters speak and run.

- schedule sales pitches instead of teaching presentations

- schedule canned pitches instead of original material

- offer too many plenary sessions, when participants have no choice of what to attend

Few conferences meet all my criteria, but I look for those conferences that do, like the three (below) that I am attending this year. I have long-ago reached a stage in my life where I cannot tolerate several days sitting in an uncomfortable chair listening to someone read bullet points from PowerPoint slides.

CAST

[http://www.associationforsoftwaretesting.org/drupal/CAST2009]

I participated in the Conference of the Association for Software Testing (CAST) last year, and I'm returning this year because the subject of the conference is precisely focused on my current interest: promoting and improving the practice of software testing.

The sessions I attended were all of high quality and interest to me. Also, it's a reasonably small conference with numerous opportunities to participate in spontaneous hall sessions.

BizConf

[http://bizconf.heroku.com/]

BizConf is a new conference this year, and I'm participating primarily because of the other participants, who, like me, are small entrepreneurs running technology businesses. It's a small conference, limited to 75 participants, and scheduled once again to encourage spontaneous hall and meal sessions. All of the presenters I know are of the highest quality.

AYE (Amplifying Your Effectiveness)

[http://www.ayeconference.com]

You might say I participate in AYE every year because I'm a host--one of the people who created the conference. But I wouldn't have been a host in the first place if I had been satisfied with most of the conferences available. When we designed the conference, we had several issues in mind in addition to the ones listed above. We wanted the conference to be reasonably priced, easy to reach, and easy to learn more about than could be found on a simple website. We created a wiki that registrants could write on and anybody could read. We retained a small staff of intelligent, personable people (Lois and Suzy) to give information and solve problems over the phone. I hope we've made it easy to get to AYE, and I hope to see you there or at one of the other two conferences I'll be attending.

Was There Process Before Agile?

Reader June Kim recently wrote:

On p.328 of Volume 4 of your Quality Software Management series, the first line goes:

"Here's another example, mixing incremental development and hacking:"

In this Chapter 18, the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping (with Hacking and Rapid Prototyping as its variants). There isn't incremental development.

"incremental development" as you wrote on that page, doesn't appear before that line in the chapter.

Is Agile An Example of Incremental Development?

QUESTION: Which process model are you referring to when you wrote "incremental development"?
Is it one among the four process models that you mentioned earlier in the chapter, or Is it something different?

ANSWER: First, you have to remember that when QSM was written, there was no "Agile" development craze. We were doing various development process, some of which were given capital letters, some which were not, and some which were "owned" by certain advocates. I was trying to be descriptive then, not favor anybody's pet process.

There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). I suppose some of them are still around, but most of the organizations I work with are now smarter than to fall for that fallacy. For the most part, every organization custom-tailored its own process (or, in most cases, processes, plural).

Of course, that's still true today. I don't find many organizations using some "pure" version of agile.

Where Do You Place Agile?

QUESTION: I am interested where you would put Agile process. I think Agile(XP and Scrum, for example) is closest to Rapid Prototyping as you described.

ANSWER: Historically, the people who first named "Agile" processes were borrowing the best of all these methods. You could also say that any agile process is a cascade (or iterative enhancement if you're actually putting each iteration's output into use). Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development.

What Happens When the Customer Won't Participate?

QUESTION: If so, it has the same danger when the customer isn't willing to be the integral part of the process.

ANSWER: That's always the case, no matter what the method, if the customer is reluctant to participate. (Until the end, when they whine, "But that's not what we wanted.")

QUESTION: What could you do in this case? Drop Agile process?

ANSWER: It's not an Agile process if the customer (or surrogate) isn't participating. In fact, I would drop any customer who doesn't participate. That's the rule I use in all my consulting, too. I don't believe you can help people who aren't willing to help themselves.

QUESTION: Or, make the customer be the part of the process? Then how? This is still a hard question to me, even with 10 years of experience in agile.

ANSWER: It's definitely one of the hardest questions with Agile or any method. Hard for most technical leaders because they lack the training and skills to work with reluctant customers.

So, I train them in these skills (a major goal of the AYE Conference and the PSL workshop), but primarily everything starts by simply pausing the work unless and until the customer has been identified and persuaded to participate.

Session Based Test Management Advice

One of the challenges of a blog on consulting is the difficulty of showing what actual consulting looks like. From time to time, though, I receive a consulting request by email which can be answered with a brief email. Brent Plumley recently sent me a request and had given me permission to blog it and my reply, so others may share, and comment.

Brent's Situation

I am currently researching methods to improve our (Session Based Test Management) SBTM debrief/review process in an attempt to make the process more efficient and scalable. Our current process has the Test Manager reviewing 100% of the testing sessions. As the testing team grows, the test manager no longer has the capacity to review all the sessions and as a result a significant backlog session list has accumulated.


- I have several areas that I was hoping you would be able to provide some insight

(1) Testing Session Debrief Trade off

- When a test session is reviewed we consider the following and attempt to achieve a 10/10 score on each.

     (a) Quality of testing performed

          - Did all the risk areas get covered

          - Were the correct test techniques implemented

          - Are there anything missing(different combinations, order of events etc...)


     (b) Quality of Testing Notes

          - Do the notes clearly outline the testing

          - Is the testing reproducible using the notes

          - Does the test properly convey the thoughts and observations

          - etc...



- As a result, the time required to perform the debriefs is quite long.



QUESTION: When performing a session debriefs should we consider a trade off between 'time', 'Quality of Testing Performed' and 'Quality of Testing Notes'. (ie. spent less time, ensure 10/10 on 'quality of testing performed' and 6/10 on 'quality of notes') or, do you think that both (a) and (b) above are important?

(2) Debrief Process

- Even if we can reduce the time spent on session reviews, as the team continues to grow, we will once again be faced with the problem of scalability (more testers = more test sessions = more time needed to review)



- We are currently considering several ways to address the scalability issue


(1) Test Sessions are reviewed by other team members (peer-review process). This will help relieve the strain on the Test Manager of having to review all test session. Also, this will provide opportunity to all test team members to learn from each others unique styles.


ANSWER: This is what I usually suggest to clients in similar situations. The number one job of any manager is to develop the people who work under their mentorship. This is an excellent way to do so.


You can introduce this leadership training opportunity incrementally, with the early leads being supervised by the manager until she finds each person prepared to lead on their own.



(2) Test Manager continues to review the test sessions but depending on the experience level of the tester, only a certain percentage of test sessions will be reviewed (ex: 100% of sessions are reviewed for junior/New testers, and 15% of test sessions for more experienced testers)


ANSWER: Absolutely not. This simply encourages people to game the system by not having their test sessions reviewed. DO NOT DO THIS.


- I have identified several problems with both of the above options. For both options, the test manager may feel out of the loop as much of the testing is not reviewed by them. Ultimately it is the test manager that is responsible for signing off on the testing that is performed. If the session notes are reviewed by peers, or not reviewed at all (only 15% of experienced testers sessions are reviewed), the test manager personally cannot guarantee perfect coverage of testing.


ANSWER: Managers must know how to delegate. If you cannot delegate, you should not be a manager.


Option 2, however, is not a matter of delegating, but of abdicating.


Again, DO NOT DO THIS.


- We are currently leading towards the Peer-Review process. This will ensure that all test sessions are reviewed by someone, which will help guarantee proper test coverage.


ANSWER: I totally agree.


QUESTION: Do you know of any other debrief processes which have been successful for other companies?


ANSWER: Not successful ones.


QUESTION: What method would you suggest for keeping the test manager informed and in the loop? We have thought of bi-weekly team meetings where key points and high level outline of testing performed is presented. Of another option, the test manager will debrief a small sample of the test sessions to get a measure of the quality of testing and debriefing performed by their team.


ANSWER: Forget the sampling. Each person who leads a review should fill out a simple report that everyone, including the test manager, can see. (For more on such reports, see my book, The Handbook of Walkthroughs, Inspections, and Technical Reviews.)


I hope this helps, Brent. It represents half a century of observations on my clients, what works and what doesn't work.



My blog readers, of course, know that no advice works in every situation, though certain mistakes seem to repeat themselves with every new generation. Brent responded by telling me the advice was helpful to him, but let me know how this advice works for you. And ask for answers and clarification.

Why We Love and Hate Meetings

Did you ever notice how many consultants have back problems? I do, from too much time in miserable seats on airplane, working on my computers at home, or sitting in boring meetings at clients' offices.

Because of my back problems, I can't bend over easily, which means I can't do an effective job of cutting my toenails. So, when I need to trim my toenails, I visit a salon for a pedicure. While having my toes clipped, I read the available magazines, such as Brides, Modern Bride, and Elegant Bride.

Bridal magazines are incredibly popular, with 135 different ones in print last time I checked. Topics include Beach Weddings, Bridal Parties, Destination Weddings, Accessories, Cakes, Ceremonies, Decorations, Dresses, Etiquette, Favors, Flowers, Gifts, Invitations, Planners, Receptions, Traditions, Trends, and many others.

Looking at all these magazines, I asked myself, "Who reads this stuff?" Well, obviously, guys don't usually read it, because nothing in the magazines evokes any emotional response—in guys. For many women, it's a different story.

From writing fiction, I've learned that emotion sells writing. My Plotbusters critique group constantly tells me that my stories don't sufficiently describe or evoke strong emotions. I didn't understand their comments, because the rest of my reader network didn't agree with them. What was the difference?

My Plotbusters colleagues are all multi-published writers, but generally not techies like the rest of my reader network. Evidently, non-techies don't fully appreciate my fiction. They say, "It's not emotional enough." Why? Because mostly the stories do not involve conflict, random violence, death, bad sex, unrequited love, and so forth.

What they do involve is smart people trying to solve problems, step by step. To me, that's not boring at all, but, indeed, extremely emotional. Tremendously exciting—which perhaps defines me as a nerd.

Which brings me back to meetings—why they bore me and cause back problems.

When I walk a client's corridors, I frequently meet people on their way to meetings. Although these same people have told me that meetings are boring, they often seem excited when they're on their way to one. Why?

Over the years, here's what I figured out. Most of my clients' people are techies—nerds like me. They find the meetings boring when they don't seem to be trying to solve problems, step by step.

At the same time, what these meetings are doing is playing out an emotional drama—conflict, blaming, flirting, one-upsmanship, random outbursts, anger, and so forth. For these happy people heading for meetings, it's those the soap-opera aspects of meetings are the most exciting parts of their jobs.

To the techies, the interest in these soap-operas is a distant second to the interest in a well-conducted problem-solving session. On the other hand, all this drama—the stuff we contemptuously call "politics"—seems to be the bread and butter of the non-techies. Indeed, these people are often upset if I show them how to conduct well-run meetings, because I've taken all the joy out of their lives.

Maybe I should bring them Brides Magazine to read in the time they save. Or perhaps Hot Rod Magazine for the guys.

Oh, and BTW, if you like to read stories of smart people trying to solve problems and be happy, take a look at my eStore.