See this Amp at http://amplify.com/u/k4ix
Thursday, December 30, 2010
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>
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
Friday, December 24, 2010
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?
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 SystemsOne 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.
Thursday, December 09, 2010
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
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
Tuesday, November 30, 2010
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)
See this Amp at http://amplify.com/u/gxdm
Friday, November 19, 2010
Technical Debt && Collins' Stages of Decline; OR, The Exponential Point of No Return
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
Wednesday, November 17, 2010
Sometimes Perception Is the Problem By Payson Hall
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
Monday, November 15, 2010
Along with The Art of War, I read this book 3-4 times a year.
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
Sunday, November 14, 2010
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
Thursday, November 11, 2010
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.
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.
Friday, October 29, 2010
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.
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.
Monday, October 25, 2010
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
Monday, October 11, 2010
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
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
Friday, October 01, 2010
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.
"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.
Wednesday, September 22, 2010
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?
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?
Wednesday, August 25, 2010
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.
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.
Sunday, August 22, 2010
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.
(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.
Thursday, August 19, 2010
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
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
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.
Read more at www.bookviewcafe.com
First Stringers is also available in trade paperback and as an ebook.
See this Amp at http://amplify.com/u/8w09
Tuesday, August 17, 2010
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).
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).
Sunday, August 15, 2010
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
Subscribe to:
Posts (Atom)
