Where Do Bad Managers Come From?

On a recent flight out of Chicago, I found myself seated next to Jack, a IT manager in a medium-sized company. Jack was on his way to interview for the IT manager in a larger corporation. He explained that he had reached the limit of his present job, and his only chance to advance himself was with a company with a larger organization.

"Why don't you stay with your present organisation and move into general management?" I asked.

"That was my goal when I took this job three years ago," Jack said, "but there's not a chance. The president of the company sees me as a technical specialist, lacking skills to become a 'real' executive. So I'm looking for someplace else, where I'll be appreciated."

"But three years isn't a very long time with one company," I said. "Perhaps they don't feel you've had enough time to prove yourself to them."

"I've done a lot for them in three years, but they don't appreciate how much work it takes to manage in the present crisis environment."

"What do you mean?"

Before I could hear his answer, one of the cabin attendants came by to ask for our choices for lunch. She beckoned the other attendant to come over and refresh our drinks. By the time all the fuss was over, we had our lunches, but I had forgotten their was an unanswered question still suspended between us. But Jack hadn't forgotten. He seemed eager to dump his woes on me while I picked at my sirloin tips.

"Technology is changing every month, and I can't find good people. It's impossible to keep a technical staff together long enough to make improvements in present systems, let alone keep up with the new technology. Junior programmers demand inflated salaries, and if they don't get them, they jump ship to some other company that is desperate enough to pay them. And senior programmers ..." He stopped talking and unrolled his cutlery.

"What about senior programmers?" I asked.

"Why talk about it?" Jack said bitterly. "There's no sense even thinking about hiring a senior person, let alone starting to search for one. You give them the moon, and a year later they want the sun. They seem to think they could get rid of us managers and run the place without us."

I could see why Jack was so bitter. In effect, he was being squeezed from both top and bottom. His management did not want to let him advance, and he felt the pressure of his own employees trying to advance up from below. Still, I had a hard time feeling sorry for Jack. I'm always suspicious of managers who speak badly of their employees.

I almost told Jack the Army saying: "There are no bad soldiers, only bad officers." Instead, I dipped the tiny spoon into my dessert custard. I had a feeling Jack wouldn't appreciate Army wisdom.

Of course Jack has problems with employees. But a manager's iob is to deal with such problems, so if Jack complains about bad people, he's telling me he's not doing his job. Jack says his people were leaving for better salaries, but salaries are roughly tenth on the list of reasons technical people switch jobs. The first reason they leave jobs is poor management. Probably the second and third reasons, too.

Jack himself was leaving his job because his own management did not understand him. They would not give him the opportunity he thought he deserved, nor would they guide him to the self-improvement he needed to advance his career.

Jack complained that his bosses never supported his requests for management training, but when I asked him about training his own people, he said: "Why invest in training them? They are going to leave before I get a return on my investment. My staff is turning over at a rate of 25 per cent a year. Technical people have no company loyalty whatsoever."

By changing jobs every three years, Jack himself was "turning over" at a rate of 33 per cent a year. His management, knowing that "technical people have no company loyalty," refused to take Jack's own executive aspirations seriously.

Jack, like so many IT managers, was locked in a "disloyalty cycle." His management did not take him seriously as a person, so he was not loyal to them. Because he was not loyal to them, they refused to take him seriously as a person. In his own career, Jack was modelling the problem he was having with his own staff.

Not every IT manager has Jack's problems. Some have broken the "disloyalty cycle," or stayed out of it in the first place. They are not panicked by the pace of technology, but insist on developing their own employees.

They may hire experienced people, but do not try to "buy" instant expertise. They know that the expertise they buy is more likely to be bought again by someone else. They have excellent technical staffs, with low turnover, but their pay scales are merely competitive, not exceptional.

Their employees tend to be loyal to their companies because they know their managers are also loyal to their companies. One of my clients has a IT manager who budgets a minimum of 20 days per year of training per employee, and woe to one of his managers who fails to reach that minimum for each employee. He does not "waste" this investment because most employees want to stay at a company that actively demonstrates loyalty to them. Sure he has some turnover, but around six per cent, rather than Jack's 25 per cent. Moreover, he tends to turn over the people he would rather lose, rather than the ones he would rather retain.

IT managers like Jack cannot have it both ways. If they want to become "real" executives, they will have to start acting like real executives. That means taking responsibility, rather than blaming their employees. It means developing good people, not trying to pirate them from other companies and then griping about how other companies are pirating from them.

But Jack does not have time to develop his employees. If he does not get promoted in three years, he will not be around to reap the benefits of his investment in them. He will be out looking for a new job that will show him more "loyalty."

"Real" executives take the long view. They are the kind of people who, at age 60, can be found planting trees. IT managers who think that fast moving technology requires short-term quick fixes are stuck in a middle management mentality. They will never become real executives.

Managing Yourself and Others

Where There’s a Will There’s a Murder

I've been slow posting on this blog for the past few weeks, and now you know why:


I've been finishing the next novel in my Residue Class Mystery Series: Where There’s a Will There’s a Murder

You can buy it now for Kindle, Nook, or at Smashwords for any other reader format. Just click the link above.


Note on PSL 
Problem Solving Leadership Workshop for May is almost full. We are considering a session for the overflow, so if you want in, get in touch with me right away. Jerry Weinberg

WIGGLE Charts—A Sketching Tool for Designers (Part 2)

Wiggle Charts (Part 2)

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique.

The following figure shows a Hierarchic WIGGLE, or a WIGGLE Visual Table of Contents (WVTOC) for use with a HIPO system. In this application of the WIGGLE, the overall size of the boxes can be used to indicate (roughly) how big an effort we anticipate in building this box. Alternatively, it can be used to approximate how much execution time or other resource we expect to be consumed here.

A WIGGLE visual table of contents from a HIPO system (Each box has input on left end, output on right.)

The next figure shows a Nassi-Shneiderman WIGGLE. In this chart, the size of the wiggles in the diagram indicates roughly how uncertain we are of the particular part of the design. 

A Nassi-Shneiderman WIGGLE

The vertical loop wiggle is quite small, perhaps indicating we're not sure if the loop is to be done N or N+1 times. Similarly, the slanted wiggles on the decision are small, indicating perhaps we don't yet know just where the "equal" case will go. But the large wiggles dividing the right branch of the decision into three boxes are very large, indicating great uncertainty about the functions to be performed here.

All these conventions may be applied to sides of boxes, regardless of the shape of the box, as well as to arrows or other lines connecting boxes. Each of these charts should be sufficiently "clear"—as sketches—to readers who can read the original, unwiggled, chart.

Just for completeness, the next figure shows a key to the use of the WIGGLE. Using this figure, you should be able to begin sketching your favorite design pictures using the WIGGLE, even if you're still in love with good old flowcharts.

The WIGGLE system condensed to a few simple rules applicable to any graphic scheme

Source

This material is adapted from my book, Rethinking Systems Analysis and Design.

A Christmas Present for My Readers: A Free Story

This year I created a Christmas present for all my faithful readers. It's about one of the characters in my series of novels, The Stringers–Ember, a blind girl with extraordinary powers. The story is titled "The Blind Warrior," and it's free.

I wanted to put the story free on Amazon.com, but Amazon took a long time to make it a free story. They finally did, but now it's too late for Christmas, so I'm doing it anyway. To obtain your copy of The Blind Warrior, go to smashwords.com. You will find the story at this address:

http://www.smashwords.com/books/view/106977?ref=JerryWeinberg

Or, on Kindle, it's at

http://www.amazon.com/dp/B006CDQEYK

And it's even on Barnes and Noble, for you Nooknicks:

http://www.barnesandnoble.com/w/the-blind-warrior-gerald-m-weinberg/1107956526?ean=2940032888451

It's free of all charges, and you can download the story in any format you need  (Smashwords has 'em all, or in more than one format). You can read the story on your computer, or you can transfer it to any other device.

Of course I have an ulterior motive. I hope you will like the story so much that you will want to read more about Ember and her Stringer friends. Or maybe you'll write a one-or-two sentence review.

Find all my books through http://www.geraldmweinberg.com, including the Stringer Series, so far.

WIGGLE Charts—A Sketching Tool for Designers

There's no sense being precise about something when you don't even know what you're talking about. - John von Neumann

For systems designers, it is the best of times and the worst of times. For years we muddled through with a few simple graphic tools for design and documentation—flowcharts, block diagrams, and perhaps decision tables. Then came the diagram explosion, with HIPO, HIPO/DB, Warnier-Orr diagrams, Softech's SADT, Nassi-Shneiderman charts, Petri nets, Constantine structure charts and data flow diagrams, Jackson data structure diagrams, and coding schemes. And for each of these diagrams, you need only bend a line or add a symbol to become known as the inventor of yet another graphic design tool.

Although the choice is large, it is really not very wide. Each of these diagrammatic schemes shares the characteristic of precision—wonderful when you know what you're talking about, but time-consuming and thought-stifling when you don't. And, since most design work is spent thinking roughly, few of these diagrams are of much help through large parts of the design process.

In other design fields, such as architecture, the rough sketch is the most frequently used graphic device, and precise detailed drawings are rarely used at all until the creative part of the design work is finished. The rough sketch has several advantages over the precise drawing:

1. It can be drawn much faster, thus using less time.

2. It represents less investment of time, so we're not afraid to throw it away and try something else.

3. It's very roughness conveys important information about where we are in the design process.

In information processing, rough sketches have always existed, but have never been glorified by a name or by favorable publicity. Schools of architecture offer courses in sketching. The student architect who makes clear quick sketches is much admired by faculty and peers alike. It's time we learned from more mature disciplines and put sketching up on a pedestal.

For many years, I've taught a method of sketching usable with most of the diagrammatic techniques now used in information processing. Although it's been received with enthusiasm, it's never received much publicity, perhaps because:

1. It doesn't require a template.

2. It doesn't have a name.

Although I'll continue to resist the template forces, I've decided to bring the baby to life with a catchy acronym, WIGGLE Charts, for Weinberg's Ideogram for Generating Graphics Lacking Exactitude.

A WIGGLE is merely a box, or block, or line, with one or more rough edges. The rough edges indicate what parts represented by the box or line are imprecisely known. For instance, the following figure is a sketch of a system using a block diagram form

A WIGGLE block diagram

Each box represents input coming from the left, processing inside, and output going to the right. Box 1 has a straight line at its left side, indicating the input to Box 1 is clearly defined somewhere. The right side, however, is rough, indicating we haven't decided what its output will be. As indicated in the diagram, some output will be passed to a second box. but we don't know exactly what. The top and bottom of Box 1 are rough lines, indicating we don't know exactly what this process will be.

Box 2 has undefined input and output, but its process is well known to us, and clearly delimited in scope. Perhaps we have decided to use an off-the-shelf sort, though we don't know which one, so we haven't decided upon a record format.

Box 3 takes the unknown output of Box 2 as its unknown input. By a process that's not yet well defined, it produces two outputs, one well defined and one known only roughly. Perhaps the first report is defined by legal requirements, or by input needs of another system, while the second output is an error report whose format is left open at this stage of the design process. The rough arrows between the boxes indicate we haven't yet decided how control will pass from one box to another. They could be subroutines of the same master routine, or steps in the same job, or separate steps manually coordinated.

Taken together, these three WIGGLE boxes and their arrows give a sketch of the overall design we have in mind. Perhaps more important is what they don't do:

1. They don't give us or any reader an unjustified feeling of precision.

2. They don't intimidate anyone who has an idea about changing something to improve the design.

3. They haven't wasted a lot of time drawing with templates.

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique. In the second half of this blog post, we'll look at a few more examples of how WIGGLE charts can be used.

(to be continued)

Source

This material on WIGGLE charts is adapted from my book, Rethinking Systems Analysis and Design.

Problem Solving Leadership Workshop (Revisited)

Today, I'm revisiting a post I put here almost exactly three years ago. At that time, I was announcing the resumption of PSL (Problem Solving Leadership Workshops). Today, I'm announcing the continuation of what has become a treasured tradition.

We're giving the next offering of the famous Problem Solving Leadership (PSL) on May 19-25, 2012, in Albuquerque, NM led by me, Esther Derby, and Johanna Rothman

The workshop's purpose is to learn and practice a consultant's most valuable asset: the ability to think and act creatively. We have designed this workshop to be practical and applicable to the modern workplace. Your problems and concerns provide a frame of reference for all
the workshop activities.

What you will learn
. to be a leader while being a member of a team
. to focus your thinking while in chaos
. to make change a productive, creative event
. to build truly effective teams
. to design projects people really want to work on
. to observe exactly what is happening
. to use tools of effective communication
. to handle conflict in problem solving groups

The workshop provides five and a half days of intensive focus on developing your unique consulting style and abilities.

Graduates Answer: "What Did You Learn in PSL?"

Janet:

My PSL course made me realize that observation alone is not enough. Sometimes you need to get in and ask questions and listen to really know what's going on.

Amy:

It's interesting to reflect on this fourteen years after the fact (Sept. 1997) of what was a profound experience.  My biggest observation was my tendency to pick problems that are too big to be solved—or at least solved all at once or on the term initially envisioned.  And my lesson was that I could turn to others and ask for help parsing the problem into resolvable packets.  I'm still using that one every day. . . when I remember to step back and observe the observer observing.

Jim (who sent me the panda picture):

I took PSL in 1983 (Jacksonville, Fl.). At the time I learned a valuable lesson about myself.  I have a tendency to cling to an obsolete and inappropriate technology long after it is no longer effective. Years later, taking training facilitated by amateurs (managers saving money on their training budget) I learned how important it is to have qualified trainers and good exercises.

Marjie:

I learned so many ways to help my teams back home become self - sufficient problem solvers by teaching. I became far more self-aware of my own behavior which was to just solve the problem and try to make life easier for everyone else when in fact, it was much more relaxing to give people the skills to solve their own problems (at least the tricks I learned at PSL) and to watch them do great things. 

I learned that Jerry's expression, "expect brilliance"—became the motto of my management style.

Sharon:

Big lessons, life-changing, agreed. The immediate lesson was: respond.  That is, I found that sometimes, in the heat of the moment, I would listen, hear, see, take in and wait, processing the inputs.  That was good.  But most important was once I did that, I should give feedback, respond, react.  Even if other people are responding, get into the mix and say what needs to be said.

The long-term lesson was that there is a fabulous community around us all.  Jerry and others became part of an extended community that has vastly changed what work I do, how I do it, and to whom I reach for support.

Becky:

Sharon, I like your point about community! I've connected with delightful, smart and engaging people who shared a similar path through JerryWorld. Not to mention the wizards who helped lead us down the path—all of those who encouraged us to be our own wizards. Gee - I hadn't thought of that. 

PSL - the gift that keeps on giving.

David:

I started learning to listen to myself, instead of asking others for validation before believing myself. Something that has served me well since then, and that I'm still learning to do better."

Rachel:

I think I'm still unpacking lessons from PSL :)

I signed up for PSL because I was uncomfortable with taking on leadership roles. I feel happier about taking the lead nowadays. For me the key is sharing passion and vision for what's possible and make it easy for people to contribute in their own way. It's important to step back and let others shape things whilst caring how things are done and being there as support when people get stuck.

I'd love to do PSL over again and also connect up with people I met there.

Jason:

I seem to have 'aha' moments often since PSL in May 2011.  A couple things stand out for me.  One, how Jerry talked about having fun and learning at work.  So simple, yet something I live by. If I'm not having fun or learning, I move on.

Second was observing the difference in outcomes between a controlling culture and cultivation culture.  I'm also amazed at in a short period of time how many people I became very close to.  It was a fantastic experience.

Zeger:

Hi all, I took PSL in May last year, and what has stuck with me, well... that's still evolving. I was an observer during the VerseWorks exercise and it struck me how much you can see and learn about what is going on in teams if you just take a step back and observe. When you're too involved, you become blind for things that are apparent to outsiders. Noticing all that going on and refraining from commenting or pointing out was quite hard. That was quite a epiphany for me. 

I also became aware of the power of silence. Doing or saying nothing can also be an act of problem-solving leadership, helping the team forward. Sometimes, less is truly more. That was a pretty sobering insight too.

Jerry:

I've "taken" PSL many, many times, and I'm still learning lessons with every workshop. Mostly, I keep learning how many wonderfully creative people are out there, always ready to take one more step toward their full potential.

If you would like more information about in this unique workshop experience, email to
jr@jrothman.com and/or take a look at http://www.estherderby.com/workshops/ProblemSolvingLeadership.htm

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.

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.

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.

Disposable Programs (Part 2)

There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap?

Part 2
I believe the answer lies in our unwillingness or inability to feed-back the true costs of programming and program maintenance to our users. Among our service bureau clients, the problem seems to have been brought to manageable proportions by the following steps:

1. When a program is commissioned, the lifespan and the number of executions must be specified.

2. If there is uncertainty about either of these figures, contingent prices are given, reflecting the differing costs.

3. The contract is written stating that the program will be destroyed after a certain time and/or number of runs, whichever comes first.

4. The program remains the property of the service bureau, unless the customer takes ownership—in which case a much higher cost is placed on the job, in order to pay for preparing the program to be taken over by other than the original programmers.

5. The customer is notified when the program is about to be destroyed, and is given the option (at a substantial and realistic price) of having the program rebuilt for further use.

6. If the program is a "one-time" program, no notification is given, but the program is destroyed—literally—as soon as the customer agrees to accept the results.

When working with inexperienced users, it is not difficult to get these terms accepted. Neither is it difficult with very experienced users, who know quite well the realities of "one-time" programs that turn out to be "N-time" programs. Only the in between users have difficulty accepting these conditions, for they believe they understand about programming, but actually have no solid basis for understanding.

After a few costly lessons, they are more than willing to sit down in advance and decide whether they want to invest in an N-time program or merely in a disposable program that will actually be disposed of.

In internal data processing situations, especially where there is no true chargeback for programming or program maintenance, these lessons are difficult to teach. There is no cost to the users of specifying a one-time program and then asking that it be run N times. Without cost, there is no motivation to learn.

Where there is chargeback, it is possible to do what good, professional service bureaus do. Without chargeback, you can sometimes achieve some relief by manipulating the one parameter you have available—time. You request the user to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use.

At first, users will not believe this procedure will be enforced. After a few lessons, they will begin to understand and devote some energy to the decision. Of course, some users will simply attack the computing center manager, or the programmer, with an axe, literal or figurative. Such are the perils of our profession. Besides, even an axe in the forehead is better than the pain in some lower anatomy caused by an immortal one-time program.

Disposable Programs

In many IT installations today, the number one problem is program maintenance.
Although the total problem is far from simple, there are a number of relatively simple ideas that can be applied immediately to furnish "prompt relief." One such idea is the disposable program.

The idea of disposable programs is not new. Every programmer has written code that was to be used once and then thrown away—codes such as:

1. First-cut subroutines, as for simple, quick formatting of output.

2. One-time reports.

3. Test drivers.

4. Research programs to probe some peculiar feature of the programming language, operating system, database, or other "black box."

5. Engineering assist programs, to help diagnose a particular hardware malfunction.

If you consider these five examples relative to your own experience, you will notice two categories:

KEPT: first-cut routines, and one-time reports, and

DISPOSED: test drivers, research programs, and hardware testers. That is, though all are thought of as single use programs, the KEPT routines tend to be held, somewhere, "just in case." Only the DISPOSED programs are actually discarded, whether they should be or not.

Can you recall an instance when you wished you had actually retained a discarded program?

And can you recall cases of KEPT programs you devoutly wish you had destroyed when you had the chance? These are the programs you see and curse almost every day, as their user phones, pleading for "just one little change."

Perhaps we would immediately begin improving the maintenance situation by applying two simple rules about "one- time" programs:

1. If you are about to throw it away, keep it.

2. If you are about to keep it, throw it away.

Unfortunately, applying these two rules together creates an infinite recursion. All programmers would be instantly paralyzed. There must be a better way. (Or do you believe that instant paralysis of all programmers would be of great benefit to the human species?)

Consider the examples once again; you'll notice that the underlying principle seems to be:

If the programmer is responsible for the decision, the program is discarded; but if the user is responsible the program is kept.

But why not just keep all programs, for all time? There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap? And how do we get out, or stay out, of the trap.

Well, we'll watch for readers' ideas on these questions, and next blog entry, I'll give a few ideas of my own.

Who is Right, and What is to Be Done About It? (2)

Today, I give the rest of the story as it actually happened, then consider some of the astute comments given already.

What the Consultant Did
The consultant was astonished by the programmer's response: "That's not an error. Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

The consultant understood, which the programmer did not, that a program error occurs when the program does not do what the customer wanted, not what the programmer thinks the customer should have wanted. That was the programmer's first mistake.

The programmer's second mistake was not understanding who his customer was. He seemed to think that the French were the customer, but the actual customer was the consultant.

(NOTE: If the actual customer had been the French, the programmer's action was still wrong, because of his first mistake. If a programmer thinks his customer has asked for the wrong thing, he could, politely, bring this thought to the customer's attention. So, if the French had been the customer, the programmer's third mistake was not bringing his thought to them. And even if the customer had been correctly identified, the programmer's fourth mistake was being rude and arrogant. That's simply not the way to get your point across, especially if your point is that your customer has been wrong.)

What the Consultant Said
"You didn't understand your assignment," the consultant said. "We're trying to simulate the precise formula used in France so we can compare it to the formula used in other countries. It's not a question of right or wrong, but merely of matching the existing French formula."

"Well," the programmer replied, "anyone with half a brain and a smattering of knowledge of inventory theory can see immediately that the French formula cannot possibly be correct, so what's the sense of programming it? Tell them to use my formula, if they want to improve their inventory management."

The management consultant decided to try another approach with the recalcitrant programmer. "That's a good idea. If you're right, I'm sure they'll really appreciate getting a better formula. In the meantime, it will help them to accept the new formula if they can see how it compares with their original one on this data, so I'd appreciate having their formula programmed as soon as you can manage."

"You don't seem to understand," the programmer insisted, "Why should I waste my valuable time on a formula I know is wrong? Just show them my formula and they'll understand."

At this point, the management consultant gave up on the programmer and got himself another one. The French formula was programmed and found to give the claimed results which were, in fact, superior in many circumstances to the approaches used in other countries. It turns out that the programmer's fifth mistake was overestimating the "correctness" of "inventory theory."

Readers' Comments
A number of readers correctly (I believe) said they would try talking with the programmer. In the actual case, the consultant tried this, but learned that the programmer was not going to listen. Perhaps this was the consultant's fault in the way he tried to talk to the programmer, but in any case, if your employee (and the programmer was, of course, working for the consultant) won't talk with you about a situation, then you have to get rid of that employee. So, attempting to talk is a good approach, in that it gives you essential information even if the programmer refuses to talk.

Other readers warned the consultant to consider his own role carefully, and to consider myriad possible interpretations of what's going on. This is always good advice for a consultant.

Several readers correctly identified one or more of the programmer's mistakes (above). Clearly, someone needs to educate the programmer about what his job is, and how to do it, but evidently the consultant lacked the skill to accomplish that. So, again, the consultant needs to consider his own role, at least for the future. In a similar situation, for example, he might take more care in choosing the programmer and/or making the programmer's task much clearer from the outset.

Those who advised the consultant to get "on the ground" with the inventory application were also on a productive track. In this case, the consultant was in the USA, and meekly accepted the refusal to pay him to travel to France and study the French approach first hand. If the consultant knew what he needed but didn't insist on having it, he made a major consulting mistake. If you insist, but your client won't supply it (time, or access, or money, or whatever), then the consultant should simply resign from that assignment.

Using specific examples rather than simply theory—what a good idea. Both the consultant and the programmer were probably "intuitives" in the MBTI sense, so they kept the discussion on the level of theory, which often misses some crucial data. In this case, if the French formula actually worked in practice, that would have thrown an entirely different light on the discussion.

Next Steps
All in all, the case example seems to have done its job—namely, stimulating an outpouring of darn good advice about consulting and programming.

Now that you have the "whole story," what further observations would you like to make as comments?

Who is Right, and What is to Be Done About It?

A management consultant, whose client was an international manufacturer, was asked to evaluate an inventory management procedure that the client had used with stunning success in their French operations. As part of his study, he wanted to compare the performance of the French procedure with procedures used in other locations, using historical data from several countries. A programmer with a strong management science background was given the job of programming the simulation of the French procedure.

When the consultant received the results he could not reconcile them with the figures supplied by the French company. After extensive checking he initiated a series of long telephone calls to France, suggesting that perhaps the procedure had not actually performed as well as they had claimed. The French management took offense at the implication of incompetence.

The French manager complained to the manager who had hired the consultant. Tempers mounted and international relations were strained to the breaking point.

By sheer chance, someone examined the programmer's simulation program and noticed that one term was missing and a second term was negative rather than positive. These findings led to a full technical review of the formula as translated. The review showed that the programmer's formula did not match the formula supplied by the French.

The consultant, much relieved, took the program back to the programmer and showed him the error. "That's not an error," the programmer protested. "Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

That's the end of Part 1.

Note to Readers
Now, for you readers, the question is this:

"If you were the consultant, how would you handle this situation going forward?"

If I receive a few comments, I'll publish the rest of the story—what actually happened.

And please note: I don't accept anonymous comments. They're automatically rejected. By all means, use a pseudonym, but don't waste your effort trying to post anonymous comments.

Iterative Development: Some History

As an old guy who's been around computing since 1950, I'm often asked about early history of computing. I appreciate efforts to capture some of our history, and try to contribute when my agin memory doesn't play tricks on me.

Back in 2003, Craig Larman and Victor R. Basili compiled an interesting article, Iterative and Incremental Development: A Brief History. I made several contributions to their history, but they did much, much more. Here's a small sample of what I told them:

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP.

When much of the same team was reassembled in Washington, DC in 1958 to develop Project Mercury, we had our own machine and the new Share Operating System, whose symbolic modification and assembly allowed us to build the system incrementally, which we did, with great success. Project Mercury was the seed bed out of which grew the IBM Federal Systems Division. Thus, that division started with a history and tradition of incremental development.

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities… I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for "software development."

Larman and Basili's article has a whole lot more to say, and as far as I know, is an accurate history. I strongly recommend that all in our profession give it a good read. We should all know these things about ourselves.

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.

Review: September issue of Tea-Time for Testers

I've just finished reading September issue of Tea-Time for Testers, a free and useful e-magazine for the testers of the world. Here's a few comments I have to offer the magazine and its readers and potential readers.

- Selena Delesie's article is a gem. I wish all testers would copy the article and use it to lay out a learning plan for themselves. She leaves us no excuses of the sort "I don't have time for learning" or "there's simply no learning opportunities where I work." On flaw: she writes, "See my website for some books, websites and blogs I recommend." I tried the link, but couldn't find the list she mentions. I wish the link went directly to the list of recommendations that's hidden somewhere in her site.

- Anurag Khode's article on testing network connection speed is on a topic that interests me. It's highly specific and useful for that reason. Conversely, for a tester without these specific problems, probably nothing is lost by skipping the article. I wish Anurag had given a few general conclusions that might help testers in other situations. As it stands, the article itself is one model of setting up tests, but I suspect few testers will take advantage of that feature unless it's specifically pointed out.

- On the other hand, I look forward to Joel Montvelisky's articles precisely because they address the issue of applying intelligence. In this article, he tackles the application of intelligence in an area that many testers think doesn't require thinking at all: automated testing. He deserves a medal for courage, because I fear that some advocates of automated testing will lambast him for suggesting that you need to think once you've automated some tests.

Anyway, those are a sampling of the articles I enjoyed in the September issue. As usual, I read TTWT from cover to cover (even though it has no covers). As for the issue as a whole, I always love the colorful illustrations throughout the issues.

You can find the latest issue at http://www.teatimewithtesters.com/

Trying to Change a Dysfunctional Organization

Today, I'm continuing my problem-solving series with a letter from Rory, asking how to change his organization. Rory's situation should be familiar to anyone who has been literally thrown into "testing" in a dysfunctional organization.

Rory
Your books have already helped me and are continuing to help me, but I have a specific scenario at work right now and I have what I think is a good solution, but I'd really appreciate your take on the matter.

I seem to be very unhappy in Variable or Routine organizations, and I really want to work in a Steering organization, but as I've learned from you they are few and far between.

Jerry
By Variable, Routine, and Steering, Rory is referring to the cultures described in my Quality Software series.

Rory
Therefore, I want to try my hand at changing the organization I work in because a) I'll be happier (I think) and b) I think the company will be better off as well. However, after re- reading Chapter 12 of "Becoming a Technical Leader" I'm very mindful of not inflicting help. I went through an exercise where I documented the situation objectively, and then observed my feelings about it. I will include what I documented below my signature. I wanted to share it with you because I thought you might find it interesting, but I'm also interested in any help you could offer on the matter.

Rory's Exercise
The situation:
- Product Manager mentioned a new scenario to me one day before the product was supposed to be released to production.

Jerry
Strike one. Strike two. And Strike three. Out already.

Rory
- The application is currently in the staging environment where testing is supposed to center around verifying the configuration is correct.

Jerry
Huh?

Rory
- The new scenario revealed a bug.

Jerry
Was anyone surprised by this?

Rory
- The developer in charge of the part that was broken updated the stored procedures to account for this.
- After testing it again there were new errors and the feature did not work at all.

Jerry
Was anyone surprised by this?

Rory
>- After an additional change the new scenario is still not working
>correctly and an old scenario is no longer working correctly.

Jerry
Was anyone surprised by this?

Rory
More context:
- The work for this feature was handed down by a manager. Each programmer was assigned a certain area of the application to code.

Jerry
Meaning the manager had already done design work?

Rory
- I started testing this on my fifth day at the company after the design reviews were completed and I report to a different manager than the programmers.
- The product manager reports to a different manager as well.
- We have never held a retrospective on the feature.
- The feature design is not documented.

Jerry
Was anyone surprised by this?

Rory
How I feel right now:
frustrated, sad, stressed, unhelpful, confused, detached from team, hopeless

How I feel about the feelings:
- I feel a little silly for letting something that is not life or death frustrate me or make me sad.
- I feel weak for not knowing how to change the situation or myself so that I don't feel these things.

Jerry
Don't try to get rid of the feelings. Instead, learn how to use them productively. If after all this, you weren't feeling frustrated, sad, stressed, unhelpful, confused, detached from team, then there would be something wrong with you.

As for hopeless, well, there isn't much hope there. There's an enormous amount to do to change an organization that acts like you've described, and you can't do it alone. So, the first step for you is to quietly see if you can recruit a few allies. If you can't, then you should leave and find a better organization.

Rory
- I feel afraid that I may lower my professional integrity in order to increase my happiness which in the long run may make me less happy.
- I feel incompetent for feeling confused.

Jerry
No, in fact, only an incompetent person would fail to feel confused in such a situation.

And just how do you mean, "lower my professional integrity" in order to increase your happiness? In my experience, people who lower their professional integrity soon become terribly unhappy that they did it. So don't!

Rory
A brief summary of what I think bothers me the most:
We aren't working together as a team on this issue, and I feel unrelated to the problem and to the other people working on it.. I believe we're working in an inefficient way which doesn't fulfill my need to become more competent at delivering quality software. My autonomy is compromised, because I feel like the developers are using me to re-test something just to check that the code fix they made worked instead of checking it themselves before taking my time. (I feel guilty for feeling that way.)

Jerry
If it's true, then there's no reason to feel guilty.

You need to be talking with people about your feelings. That's the way to find allies--or to find out there are none to be had.

Rory
I also want to sincerely help the company deliver a great product and spend as little time and money as possible to do it, and I don't see us finding ways to improve.

Jerry
You have to find others who see things that way.

Rory
What I would like to do:
If I were an outside consultant (and I was asked to help) then I would probably schedule a meeting with the actual people involved and hold a retrospective. Then I would go from there.

Jerry
That's too big a chunk from where you are. You need to recruit support, one person at a time. If you're seen to be doing this, and then you're labeled as "subversive" and/or "not a team player," then the place is hopeless.

Rory
However, I was involved in this, and I think that some people would be offended that I'm asking them to come to another meeting.

Jerry
Again, don't try to get everybody. Change happens one person at a time.

Rory
Based on this I think my best option right now is to ask someone who was not involved in the feature and who seems to have a lot of respect and admiration to schedule and facilitate a retrospective for us.

Jerry
A good idea, but it won't happen if you're the only one supporting it. Develop allies!

Hope this helps.

Switching Topics at Conference Presentations

My problem-solving letters seem to be very popular, so I'll continue this series whenever I have an interesting situation to discuss. Today, it starts with a letter from a writer colleague, let's call him Edgar.

Edgar's Letter
This weekend I'm presenting at a conference.

This morning I got a revamped schedule and suddenly I'm doing a break out session on "Coping with Foreign Withholding Taxes."

I'm in a bit of a panic because I've spent the last three months putting together a totally different presentation about "Working with Translators." Nothing like giving a presenter last minute notice. :}

Problem is, I have zero experience with foreign withholding taxes. I keep thinking I need to look into it, but have never had the time. If anyone has experience or thoughts that I could share at the conference I could really use some help.

Jerry's First Thoughts
This is an excellent example of a person offering a solution idea, rather than a problem statement. Edgar is asking for information on foreign taxes, presumably to help him cobble together a last-minute talk on the subject. In other words, he's already decided that he has to solve this problem by giving in to the organizers' totally unreasonable demands.

If he does that, his presentation will merely reveal him to be a fake, a pretender, not the real expert people at the conference would have a right to expect. In the long run, that's only going to tarnish Edgar's reputation as a professional, so I recommended a different approach altogether.

Jerry's Reply
Edgar, I sympathize with your predicament. In half a century of presenting at conferences, something similar has happened to me twice.

The first time, I didn't know how to handle it. I bungled around trying to wing it on the new topic. (I knew a bit about it, but probably not as much as some people in the audience, and in any case, I wasn't prepared.) I looked fake, and/or stupid, and news in our profession travels fast. Especially bad news.

Some years later, the same thing happened to me. This time, I knew what do do. I came to the session room a few minutes before the start time. As people arrived, I warned them that the announced topic had changed. But most people came just at the last minute, so they didn't hear my warning.

I gave them a few minutes to settle. Then I said, "The topic you see in your program is 'Coping with Foreign Withholding Taxes.' However, four months ago, when I agreed to do this session, I was told the topic was 'Working with Translators.' So, I have prepared on that topic for four months, but I haven't prepared at all for the Foreign Taxes topic. In fact, I know virtually nothing about that topic. So, if that's what you want to hear about, this isn't the place to hear it."

I went on to say, "If, however, some of you are interested in Working with Translators, stick around and I'll make my presentation."

Most of the people actually stuck around, and liked the presentation. If my topics had been like the two you mention, I might have said, "I assume you came here today because you're interested in doing business overseas. One way to help that happen is to handle the taxes wisely, but another way is to obtain good translations of your writing. After all, if you have no overseas business, you won't have any foreign taxes. So, this presentation could serve your purposes after all, especially since there are no other presentations on translations."

I may also have said (I don't remember, but I was younger and more impetuous then), "If you're unhappy about this last-minute switch, you might want to tell the conference organizers about your feelings. It won't help to tell me, as I had nothing to do with it."

References

I hope this story helps you a little. It's the best I have to offer.

If you'd like to learn more about my approach to solving problems such as this last-minute switch, you might want read one or more of my books, such as The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully; More Secrets of Consulting: The Consultant's Tool Kit; and Are Your Lights On: How to know what the problem really is.

Links to each of my books can be found on my website: http://www.geraldmweinberg.com

If you enjoyed this little essay, please sign up to come back for more.

Thanks,

Jerry