Showing posts with label challenges. Show all posts
Showing posts with label challenges. Show all posts
Saturday, December 16, 2017
My First Week in a Software Job
We were asked, "What was your first week like at your first software engineering job?"
In June, 1955, I went to work for IBM in San Francisco. Of course, at that time there was no such thing as "software engineering." In fact, there was no such thing as a "programmer." My title was "Applied Science Representative." I was supposed to apply science to the sale of IBM computers.
I was told that in two weeks I was to teach a course in programming the IBM 650.
That presented a few problems.
- I had never programmed any computer before.
- Nobody in the IBM office had ever programmed a computer before.
- Nobody in the IBM office had ever seen a computer before.
- There was no computer in the office—just a bunch of punch card machines.
- In fact, as far as we knew, there was no computer in San Francisco.
I spent the next two weeks in a closet in the IBM office studying all the IBM manuals that were stored there, preparing myself to teach this course. I was pretty much a lone ranger, without the horse or any faithful Indian companion. Actually, no companion at all.
That was over 60 years ago, and now I have a multitude of companions. Even so, it was a special time and an unforgettable first two weeks, so thank you for asking this question.
If you want to know more about what it was like in those thrilling days of yesteryear, you should follow Danny Faught's blog. Back then, we used to listen to the Lone Ranger on radio (there wasn't much, if any, television).
"Hi-Yo, Silver! A fiery horse with the speed of light, a cloud of dust and a hearty ‘Hi-Yo Silver'... The Lone Ranger! With his faithful Indian companion, Tonto, the daring and resourceful masked rider of the plains led the fight for law and order in the early Western United States . Nowhere in the pages of history can one find a greater champion of justice. Return with us now to those thrilling days of yesteryear. From out of the past come the thundering hoof-beats of the great horse Silver. The Lone Ranger rides again!"
<http://www.geraldmweinberg.com (Formerly The Lone Programmer)
Labels:
career,
challenges,
computers,
history of computers,
jobs,
learning,
programmers,
programming,
teaching
Wednesday, December 06, 2017
What is the simplest, most amazing code you have ever written or witnessed?
We were asked to describe the simplest, most amazing code we had ever written or witnessed.
My answer should probably be some esoteric APL code that I personally wrote, like inverting a matrix with a single character program, but many of my readers wouldn’t understand it. In any case, modesty prevents me from choosing my own code.
So, instead, let me tell the story that took place long ago when we were installing an IBM 709 in Bermuda, as part of the NASA space-tracking network. The 709 was a “naked” installation, with little surrounding peripheral equipment, and nothing like it in Bermuda to help us.
In particular, we didn’t have an off-line printer or a punch-card duplicator, so we needed to use the 709 itself to do these jobs—but we had no utilities because we were probably the only naked 709 in the world.
My colleague, Marilyn, who was by far the best programmer I ever knew, went to our keypunch (the only unattached peripheral we had), inserted a blank card, and proceeded to punch (in row binary) a card-to-card duplicator program for the 709. She did it as I watched, in a single pass through the keypunch.
You’d have to understand row-binary format to appreciate what a feat this was—multiple punched columns of alternate instructions in binary. To top it off, she actually punched in (in the same pass) the self-loading program AND the parity check row for her entire card.
She then loaded this card into the 709’s card reader, picked it up and reentered it as input to itself, and so punched a duplicate. She took the duplicate to the keypunch and added one punch to one of the rows. She now had a 709-to-printer program—two incredible error-free programs for the price of one.
I’ve never seen anything like it before or since. Until that time, I thought I was a pretty good programmer. After Marilyn’s feat, I realized that the best I could ever hope to be was Number Two.
How about you? Any amazing code stories to share?
Labels:
binary code,
challenges,
coding,
development,
programming
Sunday, October 29, 2017
My most challenging experience as a software developer
Here is my detailed answer to the question, "What is the most challenging experience you encountered as a software developer?:
We were developing the tracking system for Project Mercury, to put a person in space and bring them back alive. The “back alive” was the challenging part, but not the only one. Some other challenges were as follows:
-The system was based on a world-wide network of fairly unreliable teletype connections.
-We had to determine the touchdown in the Pacific to within a small radius, which meant we needed accurate and perfectly synchronized clocks on the computer and space capsule.
-We also needed to knew exactly where our tracking stations were, but it turned out nobody knew where Australia's two stations were with sufficient precision. We had to create an entire sub-project to locate Australia.
-We needed information on the launch rocket, but because it was also a military rocket, that information was classified. We eventually found a way to work around that.
-Our computers were a pair of IBM 7090s, plus a 709 at a critical station in Bermuda. In those days, the computers were not built for on-line real-time work. For instance, there was no standard interrupt clock. We actually built our own for the Bermuda machine.
-Also, there were no disk drives yet, so everything had to be based on a tape drive system, but the tape drives were not sufficiently reliable for our specs. We beat this problem by building software error-correcting codes into the tape drive system.
We worked our way through all these problems and many more smaller ones, but the most challenging problem was the “back alive” requirement. Once we had the hardware and network reliability up to snuff, we still had the problem of software errors. To counter this problem, we created a special test group, something that had never been done before. Then we set a standard that any error detected by the test group and not explicitly corrected would stop any launch.
Our tests revealed that the system could crash for unknown reasons at random times, so it would be unable to bring down the astronaut safely at a known location. When the crash occurred in testing, the two on-line printers simultaneously printed a 120-character of random garbage. The line was identical on the two printers, indicating that this was not some kind of machine error on one of the 7090s. It could have been a hardware design error or a coding error. We had to investigate both possibilities, but the second possibility was far more likely.
We struggled to track down the source of the crash, but after a fruitless month, the project manager wanted to drop it as a “random event.” We all knew it wasn’t random, but he didn’t want to be accused of delaying the first launch.
To us, however, it was endangering the life of the astronaut, so we pleaded for time to continue trying to pinpoint the fault. “We should think more about this,” we said, to which he replied (standing under an IBM THINK sign), “Thinking is a luxury we can no longer afford.”
We believed (and still believe) that thinking is not a luxury for software developers, so we went underground. After much hard work, Marilyn pinpointed the fault and we corrected it just before the first launch. We may have saved an astronaut’s life, but we’ll never get any credit for it.
Moral: We may think that hardware and software errors are challenging, but nothing matches the difficulty of confronting human errors—especially when those humans are managers willing to hide errors in order to make schedules.
Labels:
challenges,
computers,
crisis,
debugging,
error,
failures,
faults,
managers,
problem solving,
programming,
project management,
risk,
software,
software development,
testing
Monday, September 25, 2017
Dealing With Failure as a Developer
He asked, "How do I not feel like a failure when I went to one of the best schools and got one of the top internships, only to be a bad developer in the end?"
And here's what I told him:
First of all, tell yourself how lucky you are that you found out that you don’t happen to be good at development. Lots of people are good at other things, but aren’t good at development, don’t know it, and persist in doing a bad job. You should be extremely happy you’re not one of those clueless people.
Tell yourself that you failed at one thing, so far. Most people in their lives fail at many things. It’s perfectly normal.
The few people who never fail at anything are generally those who never try anything new, or risky. Tell yourself how lucky you are that you’re not one of those jerks.
When we try things, sometimes we succeed, sometimes we fail. But succeed or fail, we always have the possibility to LEARN. Many of the people who do fail at things never take up the possibility to learn, so ask yourself “What did I learn from this failure.” Keep asking like that for each failure, and you will become a very smart person.
It would also be a good idea to learn to use a different way of speaking about yourself. You are not “a failure.” You are a person who failed at something. Once. Therefore, you are a real human being. That’s pretty good, isn’t it?
For some tools to help you work through this feeling of failure, read: More Secrets of Consulting: The Consultant's Tool Kit
Labels:
challenges,
development,
emotions,
failure,
motivation,
perfection,
programming,
tools
Wednesday, August 02, 2017
Writing without the letter "A"
We were tested to see if we could write blog entries without the letter "A"
Of course we could write them. We could write lots of them. Indeed, I use this exercise in my writing courses, not just with the letter mentioned, but with every letter in English. Try it. Your writing will improve.
By the bye, some people wrote whole books without the letter E.
Try this test. Choose some letter, some difficult letter. Post some whole blog comment without using your letter.
If you would like to improve your writing, try
Oh, look. I unconsciously wrote the book title without the forbidden letter. It must be some terrific book. Multi-published reviewers think so:
"Don't write your book–build it with Weinberg's Fieldstone Method." - D. Poynter, writer of The Self-Publishing Manual
"It's changed how I intend to write my next book." - P. D., children's writer
"Buy this book. Work through the exercises…" J.R., techie writer
Labels:
challenges,
exercises,
problem solving,
writing
Saturday, April 15, 2017
Is it challenging to be a writer?
I'm often asked, "Is it challenging to be a writer?"
Knowing how many books and short items I've published, would you be surprised if I answered "No"?
Unlike many people, I would definitely answer "No." For me, NOT being a writer would be challenging.
Here’s another way to think about the “challenge” of writing:
Is it challenging to be a talker?
YES, for some people, but NO for most. You have something to say, so you open your mouth and words come out attempting to convey that “something.”
Now, the same frame for writing, at least as it is to me:
I have something to say, so I sit down by myself and words come out attempting to convey that “something.”
I suppose if I had nothing to convey, then writing would be a challenge. So far that hasn't happened.
If you're about to feel challenged, try reading Weinberg on Writing: the Fieldstone Method
This book has given thousands of writers creative and useful “things to do” when they’re about to feel challenged.
For one thing, the book is full of exercises that can get you going. In the simplest of all the exercises, all you do is take out your writing instrument (computer, pen, pencil, typewriter, ...) and write the word, "The ". Now you've started writing, so all you need now is to continue. Try it!
Labels:
challenges,
communication,
fiction,
non-fiction,
writing
Sunday, April 02, 2017
Complexity: Why We Need General Systems Thinking
It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so. - Will Rogers
The first step to knowledge is the confession of ignorance. We know far, far less about our world than most of us care to confess. Yet confess we must, for the evidences of our ignorance are beginning to mount, and their scale is too large to be ignored!
If it had been possible to photograph the earth from a satellite 150 or 200 years ago, one of the conspicuous features of the planet would have been a belt of green extending 10 degrees or more north and south of the Equator. This green zone was the wet evergreen tropical forest, more commonly known as the tropical rain forest. Two centuries ago it stretched almost unbroken over the lowlands of the humid Tropics of Central and South America, Africa, Southeast Asia and the islands of Indonesia.
... the tropical rain forest is one of the most ancient ecosystems ... it has existed continuously since the Cretaceous period, which ended more than 60 million years ago. Today, however, the rain forest, like most other natural ecosystems, is rapidly changing. ... It is likely that, by the end of this century very little will remain. - Karl Deutsch
This account may be taken as typical of hundreds filling our books, journals, and newspapers. Will the change be for good or evil? Of that, we can say nothing—that is precisely the problem. The problem is not change itself, for change is ubiquitous. Neither is the problem in the man-made origin of the change, for it is in the nature of man to change his environment. Man’s reordering of the face of the globe will cease only when man himself ceases.
The ancient history of our planet is brimful of stories of those who have ceased to exist, and many
of these stories carry the same plot: Those who live by the sword, die by the sword. The very source
of success, when carried past a reasonable point, carries the poison of death. In man, success comes
from the power that knowledge gives to alter the environment. The problem is to bring that power
under control.
In ages past, the knowledge came very slowly, and one man in his life was not likely to see much change other than that wrought by nature. The controlled incorporation of arsenic into copper to make bronze took several thousand years to develop; the substitution of tin for the more dangerous arsenic took another thousand or two. In our modern age, laboratories turn out an alloy a day, or more, with properties made to order. The alloying of metals led to the rise and fall of civilizations, but the changes were too slow to be appreciated. A truer blade meant victory over the invaders, but changes were local and slow enough to be absorbed by a million tiny adjustments without destroying the species. With an alloy a day, we can no longer be sure.
Science and engineering have been the catalysts for the unprecedented speed and magnitude of change. The physicist shows us how to harness the power of the nucleus; the chemist shows us how to increase the quantity of our food; the geneticist shows us how to improve the quality of our children. But science and engineering have been unable to keep pace with the second-order effects produced by their first-order victories. The excess heat from the nuclear generator alters the spawning pattern of fish, and, before adjustments can be made, other species have produced irreversible changes in the ecology of the river and its borders. The pesticide eliminates one insect only to the advantage of others that may be worse, or the herbicide clears the rain forest for farming, but the resulting soil changes make the land less productive than it was before. And of what we are doing to our progeny, we still have only ghastly hints.
Some have said the general systems movement was born out of the failures of science, but it would be more accurate to say the general systems approach is needed because science has been such a success. Science and technology have colonized the planet, and nothing in our lives is untouched. In this changing, they have revealed a complexity with which they are not prepared to deal. The general systems movement has taken up the task of helping scientists unravel complexity, technologists to master it, and others to learn to live with it.
In this book, we begin the task of introducing general systems thinking to those audiences. Because general systems is a child of science, we shall start by examining science from a general systems point of view. Thus prepared, we shall try to give an overview of what the general systems approach is, in relation to science. Then we begin the task in earnest by devoting ourselves to many questions of observation and experiment in a much wider context.
And then, having laboriously purged our minds and hearts of “things we know that ain’t so,” we shall be ready to map out our future general systems tasks, tasks whose elaboration lies beyond the scope of this small book.
[Thus begins the classic, An Introduction to General Systems Thinking ]
In ages past, the knowledge came very slowly, and one man in his life was not likely to see much change other than that wrought by nature. The controlled incorporation of arsenic into copper to make bronze took several thousand years to develop; the substitution of tin for the more dangerous arsenic took another thousand or two. In our modern age, laboratories turn out an alloy a day, or more, with properties made to order. The alloying of metals led to the rise and fall of civilizations, but the changes were too slow to be appreciated. A truer blade meant victory over the invaders, but changes were local and slow enough to be absorbed by a million tiny adjustments without destroying the species. With an alloy a day, we can no longer be sure.
Science and engineering have been the catalysts for the unprecedented speed and magnitude of change. The physicist shows us how to harness the power of the nucleus; the chemist shows us how to increase the quantity of our food; the geneticist shows us how to improve the quality of our children. But science and engineering have been unable to keep pace with the second-order effects produced by their first-order victories. The excess heat from the nuclear generator alters the spawning pattern of fish, and, before adjustments can be made, other species have produced irreversible changes in the ecology of the river and its borders. The pesticide eliminates one insect only to the advantage of others that may be worse, or the herbicide clears the rain forest for farming, but the resulting soil changes make the land less productive than it was before. And of what we are doing to our progeny, we still have only ghastly hints.
Some have said the general systems movement was born out of the failures of science, but it would be more accurate to say the general systems approach is needed because science has been such a success. Science and technology have colonized the planet, and nothing in our lives is untouched. In this changing, they have revealed a complexity with which they are not prepared to deal. The general systems movement has taken up the task of helping scientists unravel complexity, technologists to master it, and others to learn to live with it.
In this book, we begin the task of introducing general systems thinking to those audiences. Because general systems is a child of science, we shall start by examining science from a general systems point of view. Thus prepared, we shall try to give an overview of what the general systems approach is, in relation to science. Then we begin the task in earnest by devoting ourselves to many questions of observation and experiment in a much wider context.
And then, having laboriously purged our minds and hearts of “things we know that ain’t so,” we shall be ready to map out our future general systems tasks, tasks whose elaboration lies beyond the scope of this small book.
[Thus begins the classic, An Introduction to General Systems Thinking ]
Labels:
challenges,
change,
crisis,
history,
invention,
predicting,
science,
systems,
thinking
Monday, October 31, 2016
What's the most complex thing about software development?
What's the most complex thing about software development?
Interesting question.
So far, on Quora.com, there have been four excellent answers to this question: discussing
- the confusing role of people,
-the requirements problems,
-the interactions with the physical world.
Each of these factors certainly makes software development more complex, and processes such as Agile are designed to cope with this complexity. But, the ultimate complexity factor is software testing.
Why testing? In the software development literature, testing is not usually treated as a glamorous part of development, but when we're testing, we're up against the Second Law of Thermodynamics, which warns us that perfection is ultimately unobtainable.
So, even if we absolutely knew all the requirements (which we can't, of course), kept all the human factors under control (also impossible), and knew exactly all the physical properties of the real world (once more, impossible), we would still never be able to perform the infinite number of tests to cover all possible situations.
In other words, the software could still surprise us at any time. That's what I call complexity.
Of course, we can still work hard to solve these other problems. On requirements, for instance, see our Exploring Requirements books.
But no matter how hard you try, you'll still be faced with the testing problem. To understand this problem and what you can do to reduce (but not eliminate) it, take a look at Perfect Software and Other Illusions about Testing.
Labels:
Agile,
challenges,
communication,
development,
errors,
methodology,
perfection,
process,
quality,
requirements,
software development,
testing
Thursday, June 30, 2016
The Most Important Aspect of Software Testing
On a public forum, the question was, "What are the most important aspects of software testing?"
A number of good answers were given, but all tended to emphasize finding errors. To me, that's a limited view of testing. I would say, instead, that the most important aspect of software testing is to provide information about the state of a software product. That is, not just errors, but what's good and bad about the product. And, by the way, what's just mediocre.
For instance, the speed of the product might not be in error, but could be good, bad, medicre, or perhaps acceptable to some or all possible users. It's the tester's job to document that.
Or, there may be a feature that works okay, but is not so easy to use. Is that an error? Who knows, but in any case, it's a fact that the sponsor of the project will usually want to know about, and providing that information is the tester's job.
One more example: if a tester merely finds and reports errors, small wonder that developers feel that testers are nattering nabobs of negativity. Test reports should describe what's good—what's wonderful—about a product, and testers must never forget that part of their job.
You can read more about important aspects of testing in my book, Perfect Software And Other Illusions About Testing.
Labels:
bugs,
challenges,
computers,
debugging,
error,
information,
observation,
programming,
quality,
software,
testing
Thursday, June 16, 2016
What's something I can do right now to increase my productivity?
I was recently invited to answer the question in the heading. There were already 99 other answers, some of them very interesting. I tried reading all the answers, but gave up after the first two dozen or so. All that stuff about lists and apps and schedules and methods with trademarked-names might have been okay for some folks, but they didn't do much for me. I don't really use any of them, but I’ve been an incredibly productive person all my life.
I've published around a hundred widely acclaimed books, plus hundreds of articles. I've invented useful things and won a handful of awards for my writing. More than ten thousand people follow my tweets and my workshops are filled with people from all over the world. While doing all these things, I've also found the time and energy to support many volunteer causes.
My secret? I can do all these things because I apply just one principle:
Do what you love doing.
If you love it, you won’t need any of this tricks and tips. You might use some of them or make your own if they help you do what you love, but if you’re not doing what you love, no tricks will help much.
But, you say, "there are just some things I have to do, whether I love them or not." Well, first of all, re-examine those things and make a NOT-TO-DO list, to remind you to stop doing things you hate and don’t really have to do. And if there are still things left that you think you must do, experiment.
For instance, stop doing them for a few days or so and see if it matters. I remember when I had a job where we were supposed to put out a daily report for our manager’s manager’s manager. I started doing it every other day, and nothing happened. I switched to once a week, but again nothing happened. I cut down to once a month. Nothing.
After seven months, this senior manager finally came raging into my office demanding his daily report. I calmed him down and showed him what it had cost to do it daily when he only needed it maybe once a year. We negotiated a deal where on the day he needed it, I would drop everything and produce it in about two hours. That gave him what he needed and saved me two hours a day, 199 working days a year. Now, that’s productive.
But you may still have to accomplish a task that’s really needed, so your experiments don’t work. In that case, examine HOW you accomplish the task and use your imagination to find a way to do it that you really enjoy. For example, you can make a game of the task.
For instance, I once had a rather dull report I had to write regularly so I started each time by picking ten words at random from a large dictionary. Then I challenged myself to use all ten words somewhere in my report. Not only did this make the report into fun game, but I improved both my writing and my vocabulary. And, oh yes, people told me they enjoyed reading those reports, so maybe it made them more productive, tool.
If you enjoy doing a task, you won’t procrastinate, and you’ll do it with gusto. Voila! You’re now the most productive person around.
Not only does this principle work for you, but you can teach it to those who work with you, principally by example. When you do this, you're practicing a powerful form of leadership, helping all those other people be more productive. Think of it this way: It's the opposite of the dreaded micro-management. Instead of telling people how to do things your way, you're encouraging them to find their was to do things so they'll be a productive as you are.
Not only does this principle work for you, but you can teach it to those who work with you, principally by example. When you do this, you're practicing a powerful form of leadership, helping all those other people be more productive. Think of it this way: It's the opposite of the dreaded micro-management. Instead of telling people how to do things your way, you're encouraging them to find their was to do things so they'll be a productive as you are.
(You think I’m making this all up? Well, how many people do you know who have accomplished what I’ve accomplished. You can check my website (www.geraldmweinberg.com) and then find some other people with a comparable history and ask them if they enjoy what they do, all day. I don't think you'll find many of them who spend their day making lists—unless they've made it into a list-making game.
Labels:
art of change,
career,
challenges,
leadership,
motivation,
productivity,
writing
Sunday, January 15, 2012
Change Artist Challenge #12 Developing Yourself
A book (or a blog) can give you only what the author has to tell. But the learning that comes through self-knowledge has no limit. To learn through your own self-knowledge is to know how to listen, how to observe, and therefore you learn from everything: from music, from what people say and the way they say it, from anger, greed, ambition. - Jiddu Krishnamurti
The biggest benefit from change artistry comes when you start teaching other people to be change artists.
The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.
Source
This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.
The biggest benefit from change artistry comes when you start teaching other people to be change artists.
The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.
Source
This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.
Labels:
art of change,
books,
challenges,
change,
change artist,
future,
learning,
training
Thursday, January 05, 2012
Change Artist Challenge #11: Putting Theory Into Practice
There's nothing more practical than a good theory. - Kenneth Boulding
Reading a book is one thing. Applying what you learn is quite another. If you don't apply it soon, it simply fades away. The same is true of any educational experience. If you come back from a class and don't start using some of the material, you may as well not have gone in the first place.
The Challenge
Your challenge is to review the chapters in any of the four Quality Software Management volumes concerning specifics of the Anticipating organization and consider each idea in terms of the artistry that you can use to introduce it to your organization. Try to create at least one specific action item that will advance the transformation to that way of doing things.
Experiences
1. I started a brown bag special-interest group on our new CASE tool as a place for people who were using it to share learnings, and as a low-risk place for those who weren't using it to find out about it. The hardest part for me—and the real challenge—was to be the first speaker. I haven't been a person who enjoys speaking in front of groups, but I got some support and made myself do it. The group now runs on its own—with little nudges from me once in a while—and there's no trouble getting speakers. It has tripled in size as our use of the tool has grown, and people think that without the group the tool would have died in the original group, or at least not spread.
2. I set out to measure something that would be useful to upper management and to the people whose work was being measured. After a few false starts, I hit upon measuring resolution time for failures found in test. I set up a system to capture this data from our bug database and to plot it automatically week by week. One of the surprising things it showed was the way the new configuration management system actually slowed down resolution time. Since I was advocating the new system, I was rather disappointed, but I resisted the temptation to fudge the figures. Management wanted to throw the system out, but I invoked the Satir Change Model to get a few weeks grace period. With the help of some investigation into the causes of Chaos, the graph improved. In about three weeks, the resolution time was back to what it was before the tool, and after six weeks, the time was cut by 32%. This was the first time anyone had ever demonstrated the value of a new tool in our organization.
3. My challenge to myself was to open up information in my organization. To do this, I decided to be the model by using Public Project Progress Posters for the three projects I'm managing. I was surprised by the emotional reactions—mine and others'. I was apprehensive and defensive, yet proud of my courage. One of the other managers came into my office, shut the door, and started screaming obscenities at me for embarrassing him (because he wasn't going to post his progress). The people in the projects were generally accepting, though I spent a lot of time in the next two weeks explaining how to read the posters, what certain slippages meant, and what I was going to do about them. It was a lot more trouble than I anticipated, but now that things have settled down, it seems to be worth it.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
Reading a book is one thing. Applying what you learn is quite another. If you don't apply it soon, it simply fades away. The same is true of any educational experience. If you come back from a class and don't start using some of the material, you may as well not have gone in the first place.
The Challenge
Your challenge is to review the chapters in any of the four Quality Software Management volumes concerning specifics of the Anticipating organization and consider each idea in terms of the artistry that you can use to introduce it to your organization. Try to create at least one specific action item that will advance the transformation to that way of doing things.
Experiences
1. I started a brown bag special-interest group on our new CASE tool as a place for people who were using it to share learnings, and as a low-risk place for those who weren't using it to find out about it. The hardest part for me—and the real challenge—was to be the first speaker. I haven't been a person who enjoys speaking in front of groups, but I got some support and made myself do it. The group now runs on its own—with little nudges from me once in a while—and there's no trouble getting speakers. It has tripled in size as our use of the tool has grown, and people think that without the group the tool would have died in the original group, or at least not spread.
2. I set out to measure something that would be useful to upper management and to the people whose work was being measured. After a few false starts, I hit upon measuring resolution time for failures found in test. I set up a system to capture this data from our bug database and to plot it automatically week by week. One of the surprising things it showed was the way the new configuration management system actually slowed down resolution time. Since I was advocating the new system, I was rather disappointed, but I resisted the temptation to fudge the figures. Management wanted to throw the system out, but I invoked the Satir Change Model to get a few weeks grace period. With the help of some investigation into the causes of Chaos, the graph improved. In about three weeks, the resolution time was back to what it was before the tool, and after six weeks, the time was cut by 32%. This was the first time anyone had ever demonstrated the value of a new tool in our organization.
3. My challenge to myself was to open up information in my organization. To do this, I decided to be the model by using Public Project Progress Posters for the three projects I'm managing. I was surprised by the emotional reactions—mine and others'. I was apprehensive and defensive, yet proud of my courage. One of the other managers came into my office, shut the door, and started screaming obscenities at me for embarrassing him (because he wasn't going to post his progress). The people in the projects were generally accepting, though I spent a lot of time in the next two weeks explaining how to read the posters, what certain slippages meant, and what I was going to do about them. It was a lot more trouble than I anticipated, but now that things have settled down, it seems to be worth it.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
Labels:
art of change,
challenges,
learning,
management,
meetings,
process,
remembering,
rules
Wednesday, December 14, 2011
Change Artist Challenge #10: Learning from History
The liberation of a tree is not the freedom from its roots.- Rabindranath Tagore
The Grand Tour shows you what's going on now, but perhaps more interesting to a change artist is how things got the way they are.
The Challenge
Your challenge is to discover the history of some practice that you consider non-productive.
Experience#1
1. Darn you! This assignment almost got me fired. I started questioning why we chose our LAN software and then it came out that my boss was the one who made the study that led to the decision. We got into a BIG argument over what I considered a dumb choice that was really hurting communication around here. He gave me a copy of his original study (actually, he practically shoved it down my throat) and I grudgingly read it. I was halfway into it when I realized that they really had chosen the best that was available at that time. The system I was favoring didn't even exist then. I don't think the company that makes it even existed then. I didn't know that; I didn't even think of that. Well, I learned a couple of things:
• Don't argue with the boss until you have all your facts straight. (I suppose I knew this, but needed reinforcing.)
• Everybody really is doing the best they can, with what they have, at the time they do it.
• I'm likely to make the same mistake (if it really is a mistake) of not seeing far enough into the future.
• An apology actually works with my boss, and doesn't kill me (though it embarrasses me).
Experience#2
While studying how we used consultants in the past, I learned that we have a pattern of paying them a lot, putting in a lot of work with them, and then putting their reports on the shelf. I don't know what I'm going to do about this, but obviously something has to change. Perhaps we won't hire consultants any more, or we'll hire different ones, or we'll work with them differently. Maybe we're expecting too much from a report.
Experience#3
I found out why we put quarters in the bowl at meetings when somebody interrupts someone else. That started before I came to this group. Now we give that money to charity, but originally it was used for beer after the meeting. I've re-instituted the beer-sharing—we really needed some kind of team-building, or team-repairing like that. Don't worry, though. We still give the quarters to charity, and just take turns buying the beer.
Experience#4
I wanted to find out what really happened to the previous two process groups. I did. I'm going to make a few changes, right away.
Experience#5
Well, I couldn't do this assignment. I wanted to study the history of our weekly status meetings, but I couldn't find anyone who remembered how they got started. I couldn't find anyone who remembered why they got started. I couldn't even find anybody who knew why we were still doing them. So we're not doing them any more. But I didn't do the assignment.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
The Grand Tour shows you what's going on now, but perhaps more interesting to a change artist is how things got the way they are.
The Challenge
Your challenge is to discover the history of some practice that you consider non-productive.
Experience#1
1. Darn you! This assignment almost got me fired. I started questioning why we chose our LAN software and then it came out that my boss was the one who made the study that led to the decision. We got into a BIG argument over what I considered a dumb choice that was really hurting communication around here. He gave me a copy of his original study (actually, he practically shoved it down my throat) and I grudgingly read it. I was halfway into it when I realized that they really had chosen the best that was available at that time. The system I was favoring didn't even exist then. I don't think the company that makes it even existed then. I didn't know that; I didn't even think of that. Well, I learned a couple of things:
• Don't argue with the boss until you have all your facts straight. (I suppose I knew this, but needed reinforcing.)
• Everybody really is doing the best they can, with what they have, at the time they do it.
• I'm likely to make the same mistake (if it really is a mistake) of not seeing far enough into the future.
• An apology actually works with my boss, and doesn't kill me (though it embarrasses me).
Experience#2
While studying how we used consultants in the past, I learned that we have a pattern of paying them a lot, putting in a lot of work with them, and then putting their reports on the shelf. I don't know what I'm going to do about this, but obviously something has to change. Perhaps we won't hire consultants any more, or we'll hire different ones, or we'll work with them differently. Maybe we're expecting too much from a report.
Experience#3
I found out why we put quarters in the bowl at meetings when somebody interrupts someone else. That started before I came to this group. Now we give that money to charity, but originally it was used for beer after the meeting. I've re-instituted the beer-sharing—we really needed some kind of team-building, or team-repairing like that. Don't worry, though. We still give the quarters to charity, and just take turns buying the beer.
Experience#4
I wanted to find out what really happened to the previous two process groups. I did. I'm going to make a few changes, right away.
Experience#5
Well, I couldn't do this assignment. I wanted to study the history of our weekly status meetings, but I couldn't find anyone who remembered how they got started. I couldn't find anyone who remembered why they got started. I couldn't even find anybody who knew why we were still doing them. So we're not doing them any more. But I didn't do the assignment.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
Labels:
art of change,
challenges,
learning,
management,
meetings,
process,
remembering,
rules
Monday, October 24, 2011
Challenge 9: Organizing The Grand Tour
When you stop learning, stop listening, stop looking and asking questions, always new questions, then it's time to die... - Lillian Smith
One of the most important sources of ideas for change is ideas that have already worked in a similar organization. Moreover, one of the most supportive acts you can perform is to ask someone to teach someone else what they do well. When people teach other people about what they are doing, it forces them to become aware of their own processes.
The Challenge
Your challenge is to organize a tour of your work place for other change artists. Have the people in your workplace teach the change artists "what we do well that others might want to imitate."
Experiences
1. I thought this was a silly assignment—until it paid off with a savings of about 40,000ドル a year in our printing operation. One of the programmers on the tour had never seen an actual high-volume printer in operation. Once she understood the way things worked, she easily changed one of our major applications so that weekly printing was significantly faster.
2. We found that their performance analyzer did things that we never imagined. We felt a bit foolish using the crude tool we had concocted, but I was proud that we didn't defend it in the face of an obviously superior product (change artist training helped with that). With more than a little help from their team, we switched tools—and, as a side benefit, no longer had to maintain our homemade kludge.
3. The effect on my group was fantastic, and that really surprised me. First they grumbled about all the trouble it would be to prepare for the tour, but then they started cleaning house. It was like when my mother comes to visit—I clean the toilets and put away things that have been laying out for months. The group did the same thing with their code and their supporting documentation. I don't know if the visitors got anything out of their visit, but they sure saw a clean operation. And—this is the best thing—it stayed clean. Actually, I do think they got something out of it, because we've been asked to give four more tours to groups where someone wants to clean house.
4. Well, we didn't learn much, and they didn't learn much, except that we do things pretty much the same way. I guess that's confirming. And I learned that they're nice people. Perhaps in the future we'll be able to help each other, and that feels good even if we don't have any specific current benefits to show.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
One of the most important sources of ideas for change is ideas that have already worked in a similar organization. Moreover, one of the most supportive acts you can perform is to ask someone to teach someone else what they do well. When people teach other people about what they are doing, it forces them to become aware of their own processes.
The Challenge
Your challenge is to organize a tour of your work place for other change artists. Have the people in your workplace teach the change artists "what we do well that others might want to imitate."
Experiences
1. I thought this was a silly assignment—until it paid off with a savings of about 40,000ドル a year in our printing operation. One of the programmers on the tour had never seen an actual high-volume printer in operation. Once she understood the way things worked, she easily changed one of our major applications so that weekly printing was significantly faster.
2. We found that their performance analyzer did things that we never imagined. We felt a bit foolish using the crude tool we had concocted, but I was proud that we didn't defend it in the face of an obviously superior product (change artist training helped with that). With more than a little help from their team, we switched tools—and, as a side benefit, no longer had to maintain our homemade kludge.
3. The effect on my group was fantastic, and that really surprised me. First they grumbled about all the trouble it would be to prepare for the tour, but then they started cleaning house. It was like when my mother comes to visit—I clean the toilets and put away things that have been laying out for months. The group did the same thing with their code and their supporting documentation. I don't know if the visitors got anything out of their visit, but they sure saw a clean operation. And—this is the best thing—it stayed clean. Actually, I do think they got something out of it, because we've been asked to give four more tours to groups where someone wants to clean house.
4. Well, we didn't learn much, and they didn't learn much, except that we do things pretty much the same way. I guess that's confirming. And I learned that they're nice people. Perhaps in the future we'll be able to help each other, and that feels good even if we don't have any specific current benefits to show.
Reference
This post is part of the series, adapted from the book, Becoming a Change Artist .
Friday, August 26, 2011
Change Artist Challenge #8: Applying The Principle of Addition
The peculiar vanity of man, who wants to believe and who wants other people to believe that he is seeking after truth, when in fact it is love that he is asking this world to give him. - Albert Camus
Satir's Principle of Addition says that people change behavior by adding new behaviors, rather than getting rid of old ones. The reinforced behaviors are done more often, leaving less and less time for behaviors not reinforced.
The Challenge
Your challenge is to practice giving affirmations for behaviors you wish to increase. This can be in the form of an e-mail note, a card, a phone call, a brief office visit, a comment in the corridor. It must be done, however, directly to the person, not through some third party.
Each and every day, give one affirmation to one person.
Experiences
1. This forced me to pay attention to what people were doing.
2. This was really hard! Something deep inside me got caught in my throat when I started to form an affirmation of someone. It's a good thing I had a support group to help me figure out where that came from. I'm still not very good at it, but I can get the words out.
3. I thought I was already doing this, so it would be a really easy assignment. It turned out that nobody recognized when I was giving an affirmation, because I always cut the corners off it by some little joke, or discount.
4. I'm pretty good at this, in person, so I decided to start sending little cards to people who had done something that helped one of my change projects. Boy, was I surprised at how delighted they were! Something about a card made them really sit up and take notice; maybe it showed that I was thinking of them when they weren't present, and I took that little extra time to do this in a way that wasn't the easiest (e-mail). Maybe that made it seem extra important.
5. I made a list of people I ought to affirm, and made five copies, one for each day. I would check each one off the day's list so I would have a measure of how well I was doing. My goal was to be able to do everybody in one day by the end of the week. There were 14 people on the list, and my scores for the five days were 4, 7, 6, 11, 14. I was very proud of myself, and on Saturday I showed the list to my Will (my husband) and explained the assignment. He read over the list and told me I had forgotten someone. I was devastated: What good was a perfect score if it wasn't the whole list? But I couldn't for the life of me figure out who was left off. On Sunday, in church, I was still thinking about it and not really listening to the sermon. Will leaned over and whispered in my ear: "You." At our church, some of us stay after the service for a discussion of the sermon. God must have been watching over me when He sent the sermon that day because the subject was "Love thy neighbor as thyself." I understood that if I didn't love myself very much, loving my neighbor as myself didn't mean very much. I'd say I had a religious experience because of this exercise.
Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.
Satir's Principle of Addition says that people change behavior by adding new behaviors, rather than getting rid of old ones. The reinforced behaviors are done more often, leaving less and less time for behaviors not reinforced.
The Challenge
Your challenge is to practice giving affirmations for behaviors you wish to increase. This can be in the form of an e-mail note, a card, a phone call, a brief office visit, a comment in the corridor. It must be done, however, directly to the person, not through some third party.
Each and every day, give one affirmation to one person.
Experiences
1. This forced me to pay attention to what people were doing.
2. This was really hard! Something deep inside me got caught in my throat when I started to form an affirmation of someone. It's a good thing I had a support group to help me figure out where that came from. I'm still not very good at it, but I can get the words out.
3. I thought I was already doing this, so it would be a really easy assignment. It turned out that nobody recognized when I was giving an affirmation, because I always cut the corners off it by some little joke, or discount.
4. I'm pretty good at this, in person, so I decided to start sending little cards to people who had done something that helped one of my change projects. Boy, was I surprised at how delighted they were! Something about a card made them really sit up and take notice; maybe it showed that I was thinking of them when they weren't present, and I took that little extra time to do this in a way that wasn't the easiest (e-mail). Maybe that made it seem extra important.
5. I made a list of people I ought to affirm, and made five copies, one for each day. I would check each one off the day's list so I would have a measure of how well I was doing. My goal was to be able to do everybody in one day by the end of the week. There were 14 people on the list, and my scores for the five days were 4, 7, 6, 11, 14. I was very proud of myself, and on Saturday I showed the list to my Will (my husband) and explained the assignment. He read over the list and told me I had forgotten someone. I was devastated: What good was a perfect score if it wasn't the whole list? But I couldn't for the life of me figure out who was left off. On Sunday, in church, I was still thinking about it and not really listening to the sermon. Will leaned over and whispered in my ear: "You." At our church, some of us stay after the service for a discussion of the sermon. God must have been watching over me when He sent the sermon that day because the subject was "Love thy neighbor as thyself." I understood that if I didn't love myself very much, loving my neighbor as myself didn't mean very much. I'd say I had a religious experience because of this exercise.
Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.
Labels:
affirmation,
challenges,
change,
change artist,
reinforcement,
thinking
Thursday, August 18, 2011
Change Artist Challenge #7: Being Fully Absent
Being Fully AbsentWhoever is in a hurry shows that the thing he is about is too big for him. - Lord Chesterfield
During the Great Plague of 1666, Newton was forced to go home for a holiday when schools closed in London. While idling under a tree, he got the basic idea for his Theory of Universal Gravitation.
During the heyday of telephone exploitation (1877), Alexander Graham Bell got married and took a yearlong honeymoon in Europe! While there, he had his grand vision—not for the telephone, but for the telephone system.
So much for not being able to leave a project for vacation! As your powers as a change artist grow, it's easy to get the grandiose idea that the world can't change without you. This challenge is a challenge to that idea. It's also a way to trick you into taking care of yourself.
The Challenge
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. You must not do anything about your change artist work for a whole week, but notice what thoughts come into your head, or what apples fall on it.
Do you think you can't do this? Then you have a different assignment, suggested by Wayne Bailey: "If you're going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation."
Experiences
1. We took two weeks and went to Hawaii. It was our first vacation in seven years—really since our honeymoon. I'd always dreamed of a Pacific island paradise, and we found it. The first few days, Shanna and I drove all over the Big Island like tourists. It was interesting, but it wasn't the vacation of my dreams. Then we just starting frolicking on the beach, eating, laying about in the shade, eating, really talking to each other, eating, swimming, and eating. After about seven days of this bliss, I woke up early one morning and realized that though I hadn't consciously thought about work at all, I suddenly had a complete vision of how our process improvement program had to be restructured. Shanna was still asleep (it was real early), so I slipped out for a walk on the beach. When I got back about two hours later, I had the entire thing worked out in my mind. I didn't even have to write it down—it was so clear that I knew I couldn't forget it. Then I put it out of my mind and enjoyed the last three days of our vacation in paradise. When I got back to work, I had a new and revitalized organization. More important, I had a new and revitalized marriage.
2. I decided to spend a week hiking a segment of the Appalachian Trail. I hadn't done any backpacking for a couple of years, so I had to take out all my equipment, replace some of it, and reconsider everything. While doing that, I realized that I needed to do the same thing at work. I was so eager to get started that a little voice inside me said to forget the hike and get back to work. But I resisted. I was able to use the hike—even though it rained most of the time—as a metaphor for the changes I had to make at work. Come to think of it, that was probably because it rained all the time.
3. I stayed home and played solitaire, did jigsaw puzzles, and cleaned the house. I also rearranged my thoughts. Thank you for this assignment.
4. I went to Spain, where I could refresh my school Spanish. I spent a week in Madrid and a week in Barcelona, with a few side trips into the country. Perhaps it was living in another language for two weeks, but I didn't think of work at all. When I came back, I discovered that they had gotten along very well without me, and were eager to show me some of the nifty things they'd accomplished. At first I was depressed, thinking that I wasn't as essential as I had thought. Then I was elated when I realized that I had done a good job of preparing them to keep improving things when I wasn't there. I guess that's really the change artist's job, isn't it.
Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.
During the Great Plague of 1666, Newton was forced to go home for a holiday when schools closed in London. While idling under a tree, he got the basic idea for his Theory of Universal Gravitation.
During the heyday of telephone exploitation (1877), Alexander Graham Bell got married and took a yearlong honeymoon in Europe! While there, he had his grand vision—not for the telephone, but for the telephone system.
So much for not being able to leave a project for vacation! As your powers as a change artist grow, it's easy to get the grandiose idea that the world can't change without you. This challenge is a challenge to that idea. It's also a way to trick you into taking care of yourself.
The Challenge
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. You must not do anything about your change artist work for a whole week, but notice what thoughts come into your head, or what apples fall on it.
Do you think you can't do this? Then you have a different assignment, suggested by Wayne Bailey: "If you're going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation."
Experiences
1. We took two weeks and went to Hawaii. It was our first vacation in seven years—really since our honeymoon. I'd always dreamed of a Pacific island paradise, and we found it. The first few days, Shanna and I drove all over the Big Island like tourists. It was interesting, but it wasn't the vacation of my dreams. Then we just starting frolicking on the beach, eating, laying about in the shade, eating, really talking to each other, eating, swimming, and eating. After about seven days of this bliss, I woke up early one morning and realized that though I hadn't consciously thought about work at all, I suddenly had a complete vision of how our process improvement program had to be restructured. Shanna was still asleep (it was real early), so I slipped out for a walk on the beach. When I got back about two hours later, I had the entire thing worked out in my mind. I didn't even have to write it down—it was so clear that I knew I couldn't forget it. Then I put it out of my mind and enjoyed the last three days of our vacation in paradise. When I got back to work, I had a new and revitalized organization. More important, I had a new and revitalized marriage.
2. I decided to spend a week hiking a segment of the Appalachian Trail. I hadn't done any backpacking for a couple of years, so I had to take out all my equipment, replace some of it, and reconsider everything. While doing that, I realized that I needed to do the same thing at work. I was so eager to get started that a little voice inside me said to forget the hike and get back to work. But I resisted. I was able to use the hike—even though it rained most of the time—as a metaphor for the changes I had to make at work. Come to think of it, that was probably because it rained all the time.
3. I stayed home and played solitaire, did jigsaw puzzles, and cleaned the house. I also rearranged my thoughts. Thank you for this assignment.
4. I went to Spain, where I could refresh my school Spanish. I spent a week in Madrid and a week in Barcelona, with a few side trips into the country. Perhaps it was living in another language for two weeks, but I didn't think of work at all. When I came back, I discovered that they had gotten along very well without me, and were eager to show me some of the nifty things they'd accomplished. At first I was depressed, thinking that I wasn't as essential as I had thought. Then I was elated when I realized that I had done a good job of preparing them to keep improving things when I wasn't there. I guess that's really the change artist's job, isn't it.
Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.
Labels:
break,
challenges,
change,
change artist,
thinking,
vacation
Subscribe to:
Posts (Atom)