Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team.
Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis—leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.
We can see, then, why the democratic—or perhaps we should say "technocratic"—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside—not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning.
Indeed, once the team is selected and operating, the wise manager placed above it will adopt a "hands-off" policy with regard to its internal structure and structure change. When, as so often happens, team members come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right.
"You're right," said the rabbi, and the man left the house beaming. Soon, however, the man's wife appeared—even more distraught than the man had been.
"What do you mean," she insisted, "saying that my husband was right? You haven't heard my side of the story." And she proceeded to relate her side, finishing with a demand for a new judgment.
"You're right," said the rabbi, and the wife left satisfied. The rabbi's own wife, however, was not satisfied, for she had overheard both stories and both answers.
"How can you do that?" she demanded. "You told the husband that he was right and the wife that she was right. They can't both be right."
"You're right," said the rabbi.
[This little tale is adapted from my books: The Psychology of Computer Programming and Managing Teams Congruently.]
Sunday, March 20, 2011
Friday, March 04, 2011
A fine article, but only a sample
I chose just one of the many fine entries on the TESTHEAD blog. Read this one, then try some of the others. Michael can write--but most of all, he can think!
Amplify’d from mkl-testhead.blogspot.com
Army of One: Pairing With an Expert
One of the challenges being a lone gun tester is the fact that, often, you don’t have someone else to ask questions with. Sure you can talk to developers about issues and areas you have concerns about, but that’s not what I mean. It’s rare that time will allow a person to consistently sit down with a developer and just ask broad and open-ended questions about a product, a technique or an idea. Larger test organizations allow testers to have this opportunity. Frequently, the Army of One tester ends up doing most of their thinking or brainstorming alone… but they don’t have to.
Today I had a cool experience. One of our domain knowledge experts had some time today and asked if we could set up a pair testing session, with the idea of “asking the product some questions”. The domain expert in this case is an Attorney very well versed in Immigration Law. There are a lot of layers to testing software that services the legal profession, which my company does. While I know a fair amount about Immigration and Employment Law just by virtue of repeatedly testing and looking at the challenges our products are meant to address, I will not have the same level of experience or expertise that a dedicated attorney would have.
See this Amp at http://amplify.com/u/bsxk5
Monday, February 28, 2011
It's the publishing wave of the future
Pay attention to Mr. Lankford!
Amplify’d from www.publishersweekly.com
Waiting for a Fair E-book Split - David to Goliath: Keep the Advance
See this Amp at http://amplify.com/u/bs3ju
Sunday, February 27, 2011
Who Can Alienate Readers Better?
I'm an author who's old enough to remember when the people who ran "Big Publishing" were book people—people who had some fairly decent intuition about books and the people who read them (in other words, their products and their customers). My first book was published by McGraw-Hill They were the biggest of the big, but they treated me with respect. For example, when I spotted trouble on my royalty statement, the situation was handled personally by the company president (one of the McGraws).
Four McGraw-Hill books later, the company was having some trouble over a bogus Howard Hughes biography, and turned down every new project for a year—including my latest manuscript, The Psychology of Computer Programming. I was naive enough to be shocked that a publisher might turn down a good book, so thought I must have done something wrong. After moping for a year of self-doubt, I recovered sufficiently to circulate the book to four publishers and was offered a contract by each of them. I chose Van Nostrand.
A year later, when the printed book was delivered, I went down to NYC to receive my first copy from the hand of my editor (a ritual I had practiced with McGraw-Hill). When I suggested we go to my editor's office to sit down and talk, he told me he didn't have an office—because he had just been fired.
Turns out he'd been fired by the corporate executives for publishing my book. In the interval since contract signing, Van Nostrand had been purchased by Litton Industries, along with (as I recall) four other publishers. The idea was to convert publishing to a "proper" business model—and this was the first such acquisition/consolidation, the one that began this new era in the publishing industry.
This new model included taking editorial responsibility out of the hands of the editors (real book people) and putting it into the hands of the executives (real business people).
Apparently their business intuition told them the book wouldn't sell, but apparently that intuition didn't work. In spite of fantastic order fulfillment screw-ups (another byproduct of the acquisition/consolidation, but that's another story), The Psychology of Computer Programming outsold all other similar books in Van Nostrand's inventory. It's still selling (I got the rights back—another stupid business decision by the executives—and the book is still selling steadily after almost 40 years—over 250,000 copies in a dozen languages. (It will be out soon as an eBook.)
And, after 40 years, these business executive are still clueless about that "book business," as opposed to their "book business." If you don't believe that, watch them screwing up the eBook business in just about every imaginable way. (Nobody said they weren't creative.) For instance, here’s what MacMillan CEO John Sargent recently had to say about libraries and ebooks:
"That is a very thorny problem”, said Sargent. In the past, getting a book from libraries has had a tremendous amount of friction. You have to go to the library, maybe the book has been checked out and you have to come back another time. If it’s a popular book, maybe it gets lent ten times, there’s a lot of wear and tear, and the library will then put in a reorder. With ebooks, you sit on your couch in your living room and go to the library website, see if the library has it, maybe you check libraries in three other states. You get the book, read it, return it and get another, all without paying a thing. “It’s like Netflix, but you don’t pay for it. How is that a good model for us?"
"If there’s a model where the publisher gets a piece of the action every time the book is borrowed, that’s an interesting model." - from http://go-to-hellman.blogspot.com/2010/03/ebooks-in-libraries-thorny-problem-says.html
If you don't understand what's wrong with this statement, take a look at the article and comments, "Friday Alert: HarperCollins in cagematch with Macmillan to see who can alienate readers better." <http://dearauthor.com/wordpress/2011/02/25/friday-alert-harpercollins-in-cagematch-with-macmillan-to-see-who-can-alienate-readers-better/>
Or, if that's not helping, take a look at past history—for example, the reaction of the Western Union executives when the technology for voice-over-wire (telephone) became available. Or, study the music industry executives' bungling of the digital music scene.
Whichever example you choose, it's always the same pattern of response to new science or new technology: The people on top of the existing industry always try to stifle the new in order to preserve the old. They bungle, and that opens the door for all sorts of brash newcomers. Brash, that is, until they become the fat cats and play the same bungling role when the next innovation comes along—as it always does.
The only question is "Who will be the brash newcomers this time around?"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBook novels and nonfiction listed at these stores
• Barnes and Noble bookstore: http://tinyurl.com/4eudqk5
• Amazon Store: http://amazon.com/-/e/B000AP8TZ8
• Apple Store: http://apple.com
• Smashwords Store:
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Four McGraw-Hill books later, the company was having some trouble over a bogus Howard Hughes biography, and turned down every new project for a year—including my latest manuscript, The Psychology of Computer Programming. I was naive enough to be shocked that a publisher might turn down a good book, so thought I must have done something wrong. After moping for a year of self-doubt, I recovered sufficiently to circulate the book to four publishers and was offered a contract by each of them. I chose Van Nostrand.
A year later, when the printed book was delivered, I went down to NYC to receive my first copy from the hand of my editor (a ritual I had practiced with McGraw-Hill). When I suggested we go to my editor's office to sit down and talk, he told me he didn't have an office—because he had just been fired.
Turns out he'd been fired by the corporate executives for publishing my book. In the interval since contract signing, Van Nostrand had been purchased by Litton Industries, along with (as I recall) four other publishers. The idea was to convert publishing to a "proper" business model—and this was the first such acquisition/consolidation, the one that began this new era in the publishing industry.
This new model included taking editorial responsibility out of the hands of the editors (real book people) and putting it into the hands of the executives (real business people).
Apparently their business intuition told them the book wouldn't sell, but apparently that intuition didn't work. In spite of fantastic order fulfillment screw-ups (another byproduct of the acquisition/consolidation, but that's another story), The Psychology of Computer Programming outsold all other similar books in Van Nostrand's inventory. It's still selling (I got the rights back—another stupid business decision by the executives—and the book is still selling steadily after almost 40 years—over 250,000 copies in a dozen languages. (It will be out soon as an eBook.)
And, after 40 years, these business executive are still clueless about that "book business," as opposed to their "book business." If you don't believe that, watch them screwing up the eBook business in just about every imaginable way. (Nobody said they weren't creative.) For instance, here’s what MacMillan CEO John Sargent recently had to say about libraries and ebooks:
"That is a very thorny problem”, said Sargent. In the past, getting a book from libraries has had a tremendous amount of friction. You have to go to the library, maybe the book has been checked out and you have to come back another time. If it’s a popular book, maybe it gets lent ten times, there’s a lot of wear and tear, and the library will then put in a reorder. With ebooks, you sit on your couch in your living room and go to the library website, see if the library has it, maybe you check libraries in three other states. You get the book, read it, return it and get another, all without paying a thing. “It’s like Netflix, but you don’t pay for it. How is that a good model for us?"
"If there’s a model where the publisher gets a piece of the action every time the book is borrowed, that’s an interesting model." - from http://go-to-hellman.blogspot.com/2010/03/ebooks-in-libraries-thorny-problem-says.html
If you don't understand what's wrong with this statement, take a look at the article and comments, "Friday Alert: HarperCollins in cagematch with Macmillan to see who can alienate readers better." <http://dearauthor.com/wordpress/2011/02/25/friday-alert-harpercollins-in-cagematch-with-macmillan-to-see-who-can-alienate-readers-better/>
Or, if that's not helping, take a look at past history—for example, the reaction of the Western Union executives when the technology for voice-over-wire (telephone) became available. Or, study the music industry executives' bungling of the digital music scene.
Whichever example you choose, it's always the same pattern of response to new science or new technology: The people on top of the existing industry always try to stifle the new in order to preserve the old. They bungle, and that opens the door for all sorts of brash newcomers. Brash, that is, until they become the fat cats and play the same bungling role when the next innovation comes along—as it always does.
The only question is "Who will be the brash newcomers this time around?"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBook novels and nonfiction listed at these stores
• Barnes and Noble bookstore: http://tinyurl.com/4eudqk5
• Amazon Store: http://amazon.com/-/e/B000AP8TZ8
• Apple Store: http://apple.com
• Smashwords Store:
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Monday, February 21, 2011
The Ins and Outs of Planning a Conference Program
In response to a number of reader requests, I've asked author Marilyn Meredith to give us an essay on her experience with conference planning. She graciously consented, so here it is:
Public Safety Writers Associations’ Annual Conference
Planning the program for the Public Safety Writers Associations' annual conference is probably different in some ways for planning for other writers' conferences.
The membership is made up of active and retired law enforcement officers and firefighters, people who write articles for law enforcement and other public safety publications, non-fiction writers, and mystery writers—although there are no requirements about who can attend the conference.
When I first started with the job I had to dig a little deeper to find speakers and mainly those who came concentrated on writing topics. This year we are having some speakers who will be talking about writing topics including voice, characterization, writing thrillers, and screen writing, but we also have a police psychiatrist and a county coroner.
Some speakers have been attendees of the conference who have come to me at the conference suggesting a topic they would like to present. Others have contacted me after the conference offering their services. All of our speakers must pay for the conference just like everyone else—and there is no other compensation.
We also have panels which are usually writing topics like editing, about creating setting, writing for trade publication and promotion. This year we'll have one on writing with a partner, and a panel of experts (forensic expert, military person, lawyer, FBI agent) telling us what TV gets wrong.
It's up to me to figure out the schedule and I like to stagger the speakers in-between the panels.
We are always on a tight time-schedule; 15 minute breaks between the 45 minute presentations, so volunteers serve as time keepers, displaying signs to notify how much time is left. Some attendees love this job.
And as for the problems that occur sometimes: Once in awhile I have to switch the program around a bit because someone couldn't make it to their slot on time, or got sick, or just didn't show up. One plus to having so many professionals gathered together, there's always someone interesting who can fill in.
For anyone interested in finding out more about this conference, go to http://www.policewriter.com
Anyone wanting to be on a panel must register before June 1 so I can finalize the program, however someone can come to the conference and pay on the day it begins.
I love this conference because of all the interesting people I've met and become friends with and are invaluable for research. Because I write about a sheriff's deputy in one series and a whole police department in another, these people have become invaluable to me.
F.M. Meredith, also known as Marilyn Meredith, is the author of nearly thirty published novels. Her latest in the Rocky Bluff P.D. crime series, from Oak Tree Press, is Angel Lost. Marilyn is a member of EPIC, Four chapters of Sisters in Crime, including the Internet chapter, Mystery Writers of America, and on the board of the Public Safety Writers of America. Visit her at http://fictionforyou.com and her blog at http://marilynmeredith.blogspot.com
Angel Lost, an E. F. Meredith Crime Novel
As plans for her perfect wedding fill her mind, Officer Stacey Wilbur is sent out to trap a flasher, the new hire realizes Rocky Bluff P.D. is not the answer to his problems, Abel Navarro's can't concentrate on the job because of worry about his mother, Officer Gordon Butler has his usual upsets, the sudden appearance of an angel in the window of a furniture store captures everyone's imagination and causes problems for RBPD, and then the worst possible happens—will Stacey and Doug's wedding take place?
Sunday, February 20, 2011
Authors You May Not Know–Yet
The writing business is one of the most difficult to break into. (into which to break?) Excellent writing and story-telling are not sufficient to publicize your name and what you can do. I do my primary publicizing through my website:
http://www.geraldmweinberg.com
and through various book retailers such as Amazon, Barnes and Noble, and Smashwords.
I also belong to a number of groups of aspiring writers, including one called Backlist Books. One of the ways we spread the word about ourselves is to exchange links to our blogs and/or websites. Below, I've placed a list of some of the backlist authors I like. There's a wide variety of genres, so take a look at them and see if there's anything to your taste. You'll be glad you did.
Doranna Durgin, http://doranna.net/wordplay
Marsha Canham, http://marshacanham.wordpress.com
Jacqueline Lichtenberg, http://aliendjinnromances.blogspot.com
Jeffrey A. Carver, http://starrigger.blogspot.com/
Jill Metcalf, http://jillmetcalf.wordpress.com
Terry Odell, http://terryodell.blogspot.com
Maryann Miller, http://its-not-all-gravy.blogspot.com/
Patricia Rice, http://patriciarice.blogspot.com
Pati Nagle, http://patinagle.livejournal.com/
Lorraine Bartlett or Lorna Barrett, http://www.LornaBarrett.blogspot.com
Karen Ranney, http://karenranney.wordpress.com
http://www.geraldmweinberg.com
and through various book retailers such as Amazon, Barnes and Noble, and Smashwords.
I also belong to a number of groups of aspiring writers, including one called Backlist Books. One of the ways we spread the word about ourselves is to exchange links to our blogs and/or websites. Below, I've placed a list of some of the backlist authors I like. There's a wide variety of genres, so take a look at them and see if there's anything to your taste. You'll be glad you did.
Doranna Durgin, http://doranna.net/wordplay
Marsha Canham, http://marshacanham.wordpress.com
Jacqueline Lichtenberg, http://aliendjinnromances.blogspot.com
Jeffrey A. Carver, http://starrigger.blogspot.com/
Jill Metcalf, http://jillmetcalf.wordpress.com
Terry Odell, http://terryodell.blogspot.com
Maryann Miller, http://its-not-all-gravy.blogspot.com/
Patricia Rice, http://patriciarice.blogspot.com
Pati Nagle, http://patinagle.livejournal.com/
Lorraine Bartlett or Lorna Barrett, http://www.LornaBarrett.blogspot.com
Karen Ranney, http://karenranney.wordpress.com
Friday, February 11, 2011
No More Reviews—With Exceptions
My call for reviewers has been so successful, I'm flooded with requests for free books.
For the moment, I'd like to suspend the reviewing (until next time) with the exception of readers who are willing to review some of my novels—which are under-reviewed.
So, if you want to review one of my novels, let me know. If you're interested in one of the non-fiction, you'll have to buy it (the e-book versions are very inexpensive) or wait until the next free book offer.
For the novels, you can see them and sample them at
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
And thanks to everyone who has responded.
For the moment, I'd like to suspend the reviewing (until next time) with the exception of readers who are willing to review some of my novels—which are under-reviewed.
So, if you want to review one of my novels, let me know. If you're interested in one of the non-fiction, you'll have to buy it (the e-book versions are very inexpensive) or wait until the next free book offer.
For the novels, you can see them and sample them at
http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg
And thanks to everyone who has responded.
Thursday, February 10, 2011
Free books! Looking for a Few More Book Reviewers
This post is about marketing. As you probably know, I'm in the business of writing books, as part of my consulting business (or vice versa). In the modern publishing world, with more and more books bought online, customer reviews really can help books reach their full potential. Although we work with professional reviewers as well, you don’t need to be a professional reviewer to review books for me. Any avid reader can do it!
Right now, I'm looking for a few more people to help spread the word about my books. If you’re interested, please email me at hardpretzel (at) earthlink.net with the words “Book Reviewer” in the subject line.
I’ll email you back with a password that will give you access to one of my titles in Kindle, PDF, and ePub format, for your computer or your reading device.
Here’s my current titles, with more on the way:
http://www.geraldmweinberg.com
All I ask is that you review whatever book you download on either Amazon or Smashwords or Barnes and Noble’s website (or all three—that’s even better). If you’re a professional reviewer, it’s great if you review it on your blog or website, and I’ll often link to it from my own site, but I still ask that you post your review to at least one of the three just mentioned.
It’s easy to do, and you don’t even need to use your real name if you like. Five or six sentences is fine, though you can certainly write more if you wish. Have fun! And if you’re not sure how to do it, just read some examples.
Please note: It would be unethical to require you to do a positive review; all I ask is that you’re fair, and that if it’s just not your kind of book (remember, everyone has different tastes), that you just pass on doing the review at all. In the modern book selling world, these reviews have become critically important to helping books reach their full potential. Keep this in mind when you’re reviewing and you’ll be just fine: I’ve staked many hours on my novels and nonfiction.
I can give away only so many free books, so I’ve limited this round of book reviewers. If interested, please email us ASAP.*
(Thanks for this idea to Scott at Flying Raven Press, http://flyingravenpress.com/. Why not give them a visit.)
Right now, I'm looking for a few more people to help spread the word about my books. If you’re interested, please email me at hardpretzel (at) earthlink.net with the words “Book Reviewer” in the subject line.
I’ll email you back with a password that will give you access to one of my titles in Kindle, PDF, and ePub format, for your computer or your reading device.
Here’s my current titles, with more on the way:
http://www.geraldmweinberg.com
All I ask is that you review whatever book you download on either Amazon or Smashwords or Barnes and Noble’s website (or all three—that’s even better). If you’re a professional reviewer, it’s great if you review it on your blog or website, and I’ll often link to it from my own site, but I still ask that you post your review to at least one of the three just mentioned.
It’s easy to do, and you don’t even need to use your real name if you like. Five or six sentences is fine, though you can certainly write more if you wish. Have fun! And if you’re not sure how to do it, just read some examples.
Please note: It would be unethical to require you to do a positive review; all I ask is that you’re fair, and that if it’s just not your kind of book (remember, everyone has different tastes), that you just pass on doing the review at all. In the modern book selling world, these reviews have become critically important to helping books reach their full potential. Keep this in mind when you’re reviewing and you’ll be just fine: I’ve staked many hours on my novels and nonfiction.
I can give away only so many free books, so I’ve limited this round of book reviewers. If interested, please email us ASAP.*
(Thanks for this idea to Scott at Flying Raven Press, http://flyingravenpress.com/. Why not give them a visit.)
Friday, January 28, 2011
The Myth of Writers Block (and what to do when you're blocked)
Writing is one of the most important activities for successful consultants. Writing helps you capture and clarify your ideas. Writing helps you polish your presentations to clients. And published writing is probably the second most effective marketing tools in your kit. (First, of course, is recommendations from satisfied clients.)
Yet most consultants never publish an article. Of those who do publish an article, most write only one. Many consultants never publish a report. Of those who do publish a report, most write only one. And certainly, most consultants never publish a book. Of those who do publish a book, most publish only one. If you ask them why they don't write more, they will commonly say they are stuck, or "blocked." But these words are merely labels. They explain nothing. Most often consultants stop writing because they do not understand the essential randomness involved in the creative process.
The Structure of Creation versus the Structure of Presentation
Please don't get the impression that I read in the random way I write (my "Fieldstone Method." Reading, by its nature, is more or less linear, like a string of beads, and I tend to read most works through from beginning to end. But written works can be created by superimposing any of a variety of organizations on that linear string of words. For instance, novels, being stories, are more or less linear; but novelists may use flashbacks, stories-within-stories, or parallel stories to break the linearity.
Dictionaries, encyclopedias, and reference manuals—though consisting of a bound sequence of pages—are generally organized for a random access by the addition of tables of contents and indices. Internets and intranets allow us to hyperlink written works in much more complex structures, though in order to use them, we frequently need aids such as index pages and search engines.
But none of these reading organizations have much of anything to do with the organization of the creative process by which the works came into existence. These reading structures are presentation methods, not creation methods. Creation doesn't work in any such regular way. It's more accurately modeled by the Fieldstone Method. Every day is different; every idea is different; every mood is different; so why should every project be the same?
Writer's Block and the Goldilocks Questions
"Of course every day is different," you may say. "Some days I'm entirely paralyzed by writer's block, and I don't accomplish anything at all."
If this is your problem, I can help, as I've helped many other consultants and professional and amateur writers. I didn't always understand how I was helping, until one student wrote the following:
As evidenced in some conversations with other students of yours and in my own writings, I think there are number of intangibles that you do offer—in much the same way that a coach or therapist does. These include motivation, raising self-esteem, building confidence in writing, considering self-other-context, discipline, thinking more clearly, or awareness, to name only a few.
Writer's block is not a disorder of you, the person attempting to write. It's a deficiency of your writing methods—the mythology you've swallowed about how works get written—what my sometime co-author, Tom Gilb, calls your "mythodology." Fieldstone writers, freed of this mythodology, simply do not experience "writer's block." Have you ever heard anyone speak of “mason's block”? (But, yes, I have heard people talking about "consultant's block"—and what I'm saying here actually applies to much of the work consultants do, or try to do when they get "stuck.")
Many writing methods and books assume that writer's block results from a shortage of ideas. Others assume the opposite—that writers become blocked when they have a surplus of ideas and can't figure out what to do with all of them. But it's not the number of ideas that blocks you, it's your reaction to the number of ideas.
Here's how it goes. You have the wrong number of ideas, and that bothers you, causes you discomfort, or even pain. To lessen the pain, you turn to some other activity—coffee, beer, sex, movies, books, sleep, or name your poison. This diversion relieves the pain in the short run, but eventually your mind turns back to that unfinished piece of writing (or other work). Now you feel worse because you've avoided the task. You might try writing again, but your mind keeps returning to what a bad, blocked writer you are. So, eventually, you turn to your relief—coffee, beer, sex, or whatever.
Do you recognize the addiction cycle? (This dynamic is described more fully in my soon-to-be released Volume 5, Managing Yourself and Others, of my e-Series, Quality Software.) The Fieldstone method allows you to break this cycle in exactly the same way you break any addiction, by using your intelligence and creativity. I sometimes begin to feel "blocked," but when I do, I simply ask myself what I call the Goldilocks Questions:
"What state am I in now? Do I have too many ideas? Do I have too few? Or, like Baby Bear's porridge, is it just right?"
If I have too many ideas, I begin some organizing activities, like sorting ideas into different piles. If I have too few ideas, I concentrate on gathering more. Usually, the first place I look is in my own mind, staying in the flow of the moment, one idea building on the next.
For instance, when I’m writing dialogue, I don’t stop to search externally for just the right conversational “stone.” That approach leads to overly clever dialogue, rather than the more natural-sounding stones that just pop out of my head from millions of past conversations I’ve heard or overheard. Only if my natural mental flow fails me do I start searching for an external "fieldstone" to trigger a new flow.
Then, when the number of ideas is "just right," I organize them, trimming and polishing a bit in the process, until I have a finished product—or until I have to ask the Goldilocks Questions again. Sure, I may be stuck for a few moments, but I'm never "blocked."
In my book, Weinberg on Writing, I sketch all three parts of the Fieldstone Method—first the gathering of ideas (stones), then the organizing, then the trimming and polishing. The book describes them in that order, not because I perform them in that order, but because it's a book, and books are linear organizations of ideas.
Unlike what your schools taught you about writing, the Fieldstone Method is not dependent on any particular order of doing things. Instead, Fieldstoning is about always doing something that's advancing your projects. As a Fieldstone writer, you will have a variety of keep-moving activities, a handy list of tasks of all sizes, plus the knowledge to match each task to your mood, your start/stop time, your resources, and your total available time. As a Fieldstone consultant, you will have a second handy list of keep-moving activities—a list with your writing list as one of its sublists.
Each Fieldstone writer also has to find her own “magic” tasks, not all of which may seem “logical” to other writers. Meditation works for me, but others find it disturbing. Aikido boosts me, but it tires others. Some writers say you have to have a cat, a cigarette, and a cup of coffee laced with brandy.
The cigarette and brandied coffee would kill me, which would be merciful because then I wouldn’t have to watch the Lovey and Caro tear apart the cat.
Observing Your Activities
In order to be a non-blockable writer (or consultant), you need to do a bit of observation of yourself. Here's what I suggest you try:
1. Choose a day or several hours that you plan to devote to writing.
2. In your journal (all professional consultants keep a journal) record the start-stop time of different activities.
3. Record your feelings at the beginning and end of each activity. Don't interrupt your flow, but just capture a word or two.
4. At the end of the day, look at what you wrote in your journal. Do you see an addiction cycle?
5. How did you respond any time you were temporarily stuck?
6. What other activities could you have done that would have served you better?
7. How will you remind yourself of those activities when you repeat this observation exercise in a month or so?
(This article is adapted from Weinberg on Writing: The Fieldstone Method )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBooks sampled free, and offered for sale at these stores
• My Barnes and Noble page
• My Amazon Page
• Apple Store
• My Smashwords Page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yet most consultants never publish an article. Of those who do publish an article, most write only one. Many consultants never publish a report. Of those who do publish a report, most write only one. And certainly, most consultants never publish a book. Of those who do publish a book, most publish only one. If you ask them why they don't write more, they will commonly say they are stuck, or "blocked." But these words are merely labels. They explain nothing. Most often consultants stop writing because they do not understand the essential randomness involved in the creative process.
The Structure of Creation versus the Structure of Presentation
Please don't get the impression that I read in the random way I write (my "Fieldstone Method." Reading, by its nature, is more or less linear, like a string of beads, and I tend to read most works through from beginning to end. But written works can be created by superimposing any of a variety of organizations on that linear string of words. For instance, novels, being stories, are more or less linear; but novelists may use flashbacks, stories-within-stories, or parallel stories to break the linearity.
Dictionaries, encyclopedias, and reference manuals—though consisting of a bound sequence of pages—are generally organized for a random access by the addition of tables of contents and indices. Internets and intranets allow us to hyperlink written works in much more complex structures, though in order to use them, we frequently need aids such as index pages and search engines.
But none of these reading organizations have much of anything to do with the organization of the creative process by which the works came into existence. These reading structures are presentation methods, not creation methods. Creation doesn't work in any such regular way. It's more accurately modeled by the Fieldstone Method. Every day is different; every idea is different; every mood is different; so why should every project be the same?
Writer's Block and the Goldilocks Questions
"Of course every day is different," you may say. "Some days I'm entirely paralyzed by writer's block, and I don't accomplish anything at all."
If this is your problem, I can help, as I've helped many other consultants and professional and amateur writers. I didn't always understand how I was helping, until one student wrote the following:
As evidenced in some conversations with other students of yours and in my own writings, I think there are number of intangibles that you do offer—in much the same way that a coach or therapist does. These include motivation, raising self-esteem, building confidence in writing, considering self-other-context, discipline, thinking more clearly, or awareness, to name only a few.
Writer's block is not a disorder of you, the person attempting to write. It's a deficiency of your writing methods—the mythology you've swallowed about how works get written—what my sometime co-author, Tom Gilb, calls your "mythodology." Fieldstone writers, freed of this mythodology, simply do not experience "writer's block." Have you ever heard anyone speak of “mason's block”? (But, yes, I have heard people talking about "consultant's block"—and what I'm saying here actually applies to much of the work consultants do, or try to do when they get "stuck.")
Many writing methods and books assume that writer's block results from a shortage of ideas. Others assume the opposite—that writers become blocked when they have a surplus of ideas and can't figure out what to do with all of them. But it's not the number of ideas that blocks you, it's your reaction to the number of ideas.
Here's how it goes. You have the wrong number of ideas, and that bothers you, causes you discomfort, or even pain. To lessen the pain, you turn to some other activity—coffee, beer, sex, movies, books, sleep, or name your poison. This diversion relieves the pain in the short run, but eventually your mind turns back to that unfinished piece of writing (or other work). Now you feel worse because you've avoided the task. You might try writing again, but your mind keeps returning to what a bad, blocked writer you are. So, eventually, you turn to your relief—coffee, beer, sex, or whatever.
Do you recognize the addiction cycle? (This dynamic is described more fully in my soon-to-be released Volume 5, Managing Yourself and Others, of my e-Series, Quality Software.) The Fieldstone method allows you to break this cycle in exactly the same way you break any addiction, by using your intelligence and creativity. I sometimes begin to feel "blocked," but when I do, I simply ask myself what I call the Goldilocks Questions:
"What state am I in now? Do I have too many ideas? Do I have too few? Or, like Baby Bear's porridge, is it just right?"
If I have too many ideas, I begin some organizing activities, like sorting ideas into different piles. If I have too few ideas, I concentrate on gathering more. Usually, the first place I look is in my own mind, staying in the flow of the moment, one idea building on the next.
For instance, when I’m writing dialogue, I don’t stop to search externally for just the right conversational “stone.” That approach leads to overly clever dialogue, rather than the more natural-sounding stones that just pop out of my head from millions of past conversations I’ve heard or overheard. Only if my natural mental flow fails me do I start searching for an external "fieldstone" to trigger a new flow.
Then, when the number of ideas is "just right," I organize them, trimming and polishing a bit in the process, until I have a finished product—or until I have to ask the Goldilocks Questions again. Sure, I may be stuck for a few moments, but I'm never "blocked."
In my book, Weinberg on Writing, I sketch all three parts of the Fieldstone Method—first the gathering of ideas (stones), then the organizing, then the trimming and polishing. The book describes them in that order, not because I perform them in that order, but because it's a book, and books are linear organizations of ideas.
Unlike what your schools taught you about writing, the Fieldstone Method is not dependent on any particular order of doing things. Instead, Fieldstoning is about always doing something that's advancing your projects. As a Fieldstone writer, you will have a variety of keep-moving activities, a handy list of tasks of all sizes, plus the knowledge to match each task to your mood, your start/stop time, your resources, and your total available time. As a Fieldstone consultant, you will have a second handy list of keep-moving activities—a list with your writing list as one of its sublists.
Each Fieldstone writer also has to find her own “magic” tasks, not all of which may seem “logical” to other writers. Meditation works for me, but others find it disturbing. Aikido boosts me, but it tires others. Some writers say you have to have a cat, a cigarette, and a cup of coffee laced with brandy.
The cigarette and brandied coffee would kill me, which would be merciful because then I wouldn’t have to watch the Lovey and Caro tear apart the cat.
Observing Your Activities
In order to be a non-blockable writer (or consultant), you need to do a bit of observation of yourself. Here's what I suggest you try:
1. Choose a day or several hours that you plan to devote to writing.
2. In your journal (all professional consultants keep a journal) record the start-stop time of different activities.
3. Record your feelings at the beginning and end of each activity. Don't interrupt your flow, but just capture a word or two.
4. At the end of the day, look at what you wrote in your journal. Do you see an addiction cycle?
5. How did you respond any time you were temporarily stuck?
6. What other activities could you have done that would have served you better?
7. How will you remind yourself of those activities when you repeat this observation exercise in a month or so?
(This article is adapted from Weinberg on Writing: The Fieldstone Method )~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Find my eBooks sampled free, and offered for sale at these stores
• My Barnes and Noble page
• My Amazon Page
• Apple Store
• My Smashwords Page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tuesday, January 04, 2011
The Universal Pattern of Huge Software Losses
What Do Failures Cost?
Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In Responding to Significant Software Events, I give five examples that should convince you.
The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.
A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program. A slight error in one constant was multiplied by millions of customers, adding up to X dollars that the utility could never recover. The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.
I know of the next case through the public press, so I can tell you that it's about the New York State Lottery. The New York State legislature authorized a special lottery to raise extra money for some worthy purpose. As this special lottery was a variant of the regular lottery, the program to print the lottery tickets had to be modified. Fortunately, all this involved was changing one digit in the existing program. A tiny error caused duplicate tickets to be printed, and public confidence in the lottery plunged with a total loss of revenue estimated between $44 million and $55 million.
I know the next story from the outside, as a customer of a large brokerage firm:
One month, a spurious line of $100,000.00 was printed on the summary portion of 1,500,000 accounts, and nobody knew why it was there. The total cost of this failure was at least $2,000,000, and the failure resulted from one of the simplest known errors in COBOL coding: failing to clear a blank line in a printing area.
I know this story, too, from the outside, as a customer of a mail-order company, and also from the inside, as their consultant. One month, a new service phone number for customer inquiries was printed on each bill. Unfortunately, the phone number had one digit incorrect, producing the number of a local doctor instead of the mail-order company. The doctor's phone was continuously busy for a week until he could get it disconnected. Many patients suffered, though I don't know if anyone died as a result of not being able to reach the doctor. The total cost of this failure would have been hard to calculate except for the fact that the doctor sued the mail-order company and won a large settlement.
The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:
1. There is an existing system in operation, and it is considered reliable and crucial to the operation.
2. A quick change to the system is desired, usually from very high in the organization.
3. The change is labeled "trivial."
4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.
5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.
6. The change is put directly into the normal operations.
7. The individual effect of the change is small, so that nobody notices immediately.
8. This small effect is multiplied by many uses, producing a large consequence.
Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:
9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.
10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.
11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]
12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.
13. Higher managers are left untouched. After all, what could they have done?
The First Rule of Failure Prevention
Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:
• "This is a trivial change."
• "What can possibly go wrong?"
• "This won't change anything."
When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention:
Nothing is too small to be unworthy of observing.
It doesn't have to be that way
Disaster stories always make good news, but as observations, they distort reality. If we consider only software engineering disasters, we omit all those organizations that are managing effectively. But good management is so boring! Nothing ever happens worth putting in the paper. Or almost nothing. Fortunately, we occasionally get a heart-warming story such as Financial World telling about Charles T. Fisher III of NBD Corporation, one of their award-winning CEO's for the Eighties:
"When Comerica's computers began spewing out erroneous statements to its customers, Fisher introduced Guaranteed Performance Checking, promising $10 for any error in an NBD customer's monthly statement. Within two months, NBD claimed 15,000 new customers and more than $32 million in new accounts."
What the story doesn't tell is what happened inside the Information Systems department when they realized that their CEO, Charles T. Fisher III, had put a value on their work. I wasn't present, but I could guess the effect of knowing each prevented failure was worth $10 cash.
The Second Rule of Failure Prevention
One moral of the NBD story is that those other organizations do not know how to assign meaning to their losses, even when they finally observed them. It's as if they went to school, paid a large tuition, and failed to learn the one important lesson—the First Principle of Financial Management, which is also the Second Rule of Failure Prevention:
A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars.
Will these other firms ever realize that exposure to a potential billion dollar loss has to be the responsibility of their highest ranking officer? A programmer who is not even authorized to make a long distance phone call can never be responsible for a loss of a billion dollars. Because of the potential for billion dollar losses, reliable performance of the firm's information systems is a CEO level responsibility.
Of course I don't expect Charles T. Fisher III or any other CEO to touch even one digit of a COBOL program. But I do expect that when the CEOs realize the value of trouble-free operation, they'll take the right CEO-action. Once this happens, this message will then trickle down to the levels that can do something about it—along with the resources to do something about it.
Learning from others
Another moral of all these stories is that by the time you observe failures, it's much later than you think. Hopefully, your CEO will read about your exposure in these case studies, not in a disaster report from your office. Better to find ways of preventing failures before they get out of the office.
Here's a question to test your software engineering knowledge:
What is the earliest, cheapest, easiest, and most practical way to detect failures?
And here's the answer that you may not have been expecting:
The earliest, cheapest, easiest, and most practical way to detect failures is in the other guy's organization.
Over my half-century in the information systems business, there have been many unsolved mysteries. For instance, why don't we do what we know how to do? Or, why don't we learn from our mistakes? But the one mystery that beats all the others is why don't we learn from the mistakes of others?
Cases such as those cited above are in the news every week, with strong impact on the general public's attitudes about computers. But they seem to have no impact at all on the attitudes of software engineering professionals. Is it because they are such enormous losses that the only safe psychological reaction is, "It can't happen here (because if it did, I would lose my job, and I can't afford to lose my job, therefore I won't think about it)"?
(Adapted from Responding to Significant Software Events )http://www.smashwords.com/books/view/35783
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>
See this Amp at http://amplify.com/u/k4ix
Resolution #1 for the new year
New Year Resolution #1: Make all my writings available in all eBook formats, so I'm free to write some more novels, stories & non-fiction. <http://www.smashwords.com/profile/view/JerryWeinberg>
See this Amp at http://amplify.com/u/k4hx
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?
Subscribe to:
Posts (Atom)
