Gifts for Any Time, but Especially Now

It's the week before Christmas,

And all through the house,

Every creature was fretting

And feeling like a louse.

Without any warning

A gift I had gotten

From a friendly old colleague

Whose gift I'd forgotten.

But then I remembered

Don't feel like a schnook

In just a few minutes

I can send a fine book

No wrapping, no breakage,

No address to scrawl,

No trade-ins, no trouble,

'Cause one size fits all.

So boot up your browser,

There's no need to grovel

In a fistful of keystrokes

You can send an e-novel.

Naturally, I recommend one of my novels for a fun read:

Women of Power Series

   Mistress of Molecules

   The Hands of God

   Earth’s Endless Effort

The Stringers Series

   First Stringers: or eyes that do not see

   Second Stringers: the sole advantage

The Residue Class Mystery Series

   Freshman Murders

   Where There’s a Will There’s a Murder

The Aremac Series

   The Aremac Project

   Aremac Power: Inventions at Risk

  

For just $4.99, you can go to http://www.geraldmweinberg.com/Site/Novels.html and send your friend an engaging, exciting story, one that also carries one or more science/technology theme: my attempt to put the science back in science fiction and the tech back in techno-thrillers.

The themes in The Freshman Murders are Computers, Culture, and Genealogy.

The themes in Where There's a Will There's a Murder are Mathematics and Anthropology.

The themes in First Stringers and Second Stringers are Physics, Chemistry, and Social Psychology.

The themes in Mistress of Molecules are Chemistry and Politics.

In The Hands of God, the themes are Parallel Computing, Neurophysiology, and Prosthetics.

The Aremac Project and Aremac Power emphasize software testing, security, and the risks and rewards of invention.

Earth’s Endless Effort features large, unconventional computers and the contact with alien species.

And, of course, always Computers! And always an exciting story.

And if you've already gifted everyone on your list, I invite you to try one of my novels for yourself. As always, if you don’t like it, I’ll gladly give you your money back.

Why People Don't Instantly Buy Into Agile Methods: A Catch-22

When "selling" their methods, Agile evangelists often stress the strength of Agile methods at removing, and even preventing, errors. I used to do this myself, but I always wondered how people could resist this sales pitch. I would plead, "Don't you want quality?" And, of course, they always said, "Yes, we want quality," but they didn't buy what I was selling. Eventually, I learned the reason, or at least one of the reasons. In today's blog, I want to help today's evangelists (coaches, team leaders, managers, or whomever) by sharing what I've learned about why Agile methods can be so difficult to sell.

Another Story About Quality

In a prior essay, I told a story that demonstrated how "quality" is relative to particular persons. To test our understanding of this definition, as well as its applicability, let's read another story, one that illustrates that quality is not merely the absence of error.

One of the favorite pastimes of my youth was playing cribbage with my father. Cribbage is a card game, invented by the poet Sir John Suckling, very popular in some regions of the world, but essentially unknown in others. After my father died, I missed playing cribbage with him and was hard pressed to find a regular partner. Consequently, I was delighted to discover a shareware cribbage program for the Macintosh: "Precision Cribbage" by Doug Brent, of San Jose, CA.

Precision Cribbage was a rather nicely engineered piece of software, I thought, especially when compared with the great majority of shareware. I was especially pleased to find that it gave me a challenging game, though it wasn't good enough to beat me more than 1 or 2 games out of 10. Doug had requested a postcard from my home town as a shareware fee. I played many happy games of Precision Cribbage, so I was pleased to send Doug this minimum fee.

Soon after I sent the card, though, I discovered two clear errors in the scoring algorithm of Precision Cribbage. (Perhaps the word "precision" in the name should have been a clue. If it was indeed precise, there was no need to call it "precision." The software would have spoken for itself. I often use that observation about product names to begin my evaluation of a project. For instance, whenever a product has the word "magic" in its title, I steer clear of the whole mess.)

One error in Precision Cribbage was an intermittent failure to count correctly hands with three cards of one denomination and two of another (a "full house," in poker terminology). This was clearly an unintentional flaw, because sometimes such hands were counted correctly.

The second error, however, may have been a misunderstanding of the scoring rules (which were certainly part of the "requirements" for a program that purported to play a card game). It had to do with counting hands that had three cards of the same suit when a fourth card of that suit turned up when the deck was cut. In this case, I could actually prove mathematically that the algorithm was incorrect.

So what makes this story relevant? Simply this: even with two scoring errors in the game, I was sufficiently satisfied with the quality of Precision Cribbage to

a. keep on playing it, for at least several of my valuable hours each week

b. pay the shareware "fee," even though I could have omitted payment with no fear of retribution of any kind

In short, Precision Cribbage had great value to me, value which I was willing and able to demonstrate by spending my own time and (if requested) money. Moreover, had Doug corrected these errors, it would have added very little to the value of the software.

What's Happening to Quality?

My experience with Precision Cribbage took place some years ago, and occured in a more-or-less amateur piece of shareware. Certainly, with all we've learned over the past few decades, the rate of software errors has diminished. Or has it?

I've conducted a small survey of more modern software. Software written by professionals. Software that I use regularly. Software I paid real money for. And not software for playing games, but software used for serious tasks in my business. Here's what I found:

Out of the 20 apps I use most frequently, 16 have bugs that I have personally encountered–bugs that have cost me at least inconvenience and sometime many hours of fix-up time, but at least one hour for each occurence. If I value my time at a conservativer $100/hour (I actually bill at $500/hour), these bugs cost me approximately $5,000 in the month of August. That's $60,000 a year, if I maintain that average.

If I consider only the purchase prices, those 20 apps cost me about $3,500. In other words, over one year, the purchase price of the software represents less than 10% of what it costs me. (And these are selected apps. The ones that are even buggier have been discarded any time I can find a plausible substitute.) In other words, since quality is value, there's a large negative quality associated with this set of applications.

And that's only for one person. In the USA, there must be at least 100,000,000 users of personal computers. My hourly rate is probably higher than the average, so let's just estimate $10/hour, roughly minimum wage for the average person. That would give us an estimate $6,000/year per person for buggy software, which adds up to about $600,000,000,000 for the annual cost to United States workers. Even if my estimates are way off, that's not chump change.

Why Is Improving Quality So Difficult?

If they payoff is so huge, why aren't we raising software quality to new levels? We could ask the same question about improving auto safety, where tens of thousands of human lives are destroyed every year in the United States. You might think that's more motivation than any number of dollars, but it doesn't work that way. Unless the person killed in the car is someone we know, we've heard about so many traffic deaths that we've grown immune to the terrible cost. In other words, it's precisely because traffic deaths are so common that we don't get awfully excited about them.

And, I believe, it's the same with software failures. They're so common that we've learned to take them with an accepting shrug. We simply reboot and get back to work. Very seldom do we even bother to switch to a different app. The old one, with all its bugs, is too familar, too comfortable. In fact, some people obtain most of their job security precisely because of their familiarity with software bugs and ways to work around them.

In other words, we're surprised that people don't generally feel motivated to improve quality because we vastly underrate the value of the familiar. And that observation explains an interesting paradox. Agile advocates are often so eager to prove the value of Agile methods that they strive to create products with all sorts of wonderful new features. But each new feature, no matter how potentially valuable, has a downside–a negative quality value because of its unfamiliarity. The harder we strive to produce "higher quality," the lower the quality we tend to produce.

It's a classic catch-22. To convince people of the value of Agile, we need to produce software that is full of wonderful features that the old software didn't possess, at the same time the new software functions exactly the way the old software did. No wonder change is difficult.

Agile and the Definition of Quality

Some Agile writers have called me "the grandfather of Agile." I choose to interpret that comment as a compliment, rather than a disparagment of my advanced age. As a grandfather, much of my most influential writing was done long before the Agile movement appeared on stage. As a result, newcomers on the scene often fail to see the connection between those writings and today's Agile movement.

I'm planning to use my blog to correct that situation, with a series of articles relating specific material to Agile basics. I'm starting with this blog entry about my definition of "quality"–often quoted by not always understood. The essay is adapted from the very first chapter of How Software is Built, which in turn is adapted my the first volume of Quality Software Management. <http://www.geraldmweinberg.com/Site/QSM_vol_1.html>

A Bug in the Family

My sister's daughter, Terra, is the only one in the family who has followed Uncle Jerry in the writer's trade. She writes fascinating books on the history of medicine, and I follow each one's progress as if it were one of my own. For that reason, I was terribly distressed when her first book, Disease in the Popular American Press, came out with a number of gross typographical errors in which whole segments of text disappeared. I was even more distressed to discover that those errors were caused by an error in the word processing software she used–CozyWrite, published by one of my clients, the MiniCozy Software Company.

Terra asked me to discuss the matter with MiniCozy on my next visit. I located the project manager for CozyWrite, and he acknowledged the existence of the error.

"It's a rare bug," he said.

"I wouldn't say so," I countered. "I found over twenty-five instances in her book."

"But it would only happen in a book-sized project. Out of over 100,000 customers, we probably didn't have 10 who undertook a project of that size as a single file."

"But my niece noticed. It was her first book, and she was devastated."

"Naturally I'm sorry for her, but it wouldn't have made any sense for us to try to fix the bug for 10 customers."

"Why not? You advertise that CozyWrite handles book-sized projects."

"We tried to do that, but the features didn't work. Eventually, we'll probably fix them, but for now, chances are we would introduce a worse bug–one that would affect hundreds or thousands of customers. I believe we did the right thing."

As I listened to this project manager, I found myself caught in an emotional trap. As software consultant to MiniCozy, I had to agree, but as uncle to an author, I was violently opposed to his line of reasoning. If someone at that moment had asked me, "Is CozyWrite a quality product?" I would have been tongue-tied.

How would you have answered?

The Relativity of Quality

The reason for my dilemma lies in the relativity of quality. As the MiniCozy story crisply illustrates, what is adequate quality to one person may be inadequate quality to another.

Finding the relativity

If you examine various definitions of quality, you will always find this relativity. You may have to examine with care, though, for the relativity is often hidden, or at best, implicit.

Take for example Crosby's definition:

"Quality is meeting requirements."

Unless your requirements come directly from heaven (as some developers seem to think), a more precise statement would be:

"Quality is meeting some person's requirements."

For each different person, the same product will generally have different "quality," as in the case of my niece's word processor. My MiniCozy dilemma is resolved once I recognize that

a. To Terra, the people involved were her readers.

b. To MiniCozy's project manager, the people involved were (the majority of) his customers.

Who was that masked man?

In short, quality does not exist in a non-human vacuum, but every statement about quality is a statement about some person(s).

That statement may be explicit or implicit. Most often, the "who" is implicit, and statements about quality sound like something Moses brought down from Mount Sinai on a stone tablet. That's why so many discussions of software quality are unproductive: It's my stone tablet versus your Golden Calf.

When we encompass the relativity of quality, we have a tool to make those discussions more fruitful. Each time somebody asserts a definition of software quality, we simply ask,

"Who is the person behind that statement about quality."

Using this heuristic, let's consider a few familiar but often conflicting ideas about what constitutes software quality:

a. "Zero defects is high quality."

1. to a user such as a surgeon whose work would be disturbed by those defects

2. to a manager who would be criticized for those defects

b. "Lots of features is high quality."

1. to users whose work can use those features–if they know about them

2. to marketers who believe that features sell products

c. "Elegant coding is high quality."

1. to developers who place a high value on the opinions of their peers

2. to professors of computer science who enjoy elegance

d. "High performance is high quality."

1. to users whose work taxes the capacity of their machines

2. to salespeople who have to submit their products to benchmarks

e. "Low development cost is high quality."

1. to customers who wish to buy thousands of copies of the software

2. to project managers who are on tight budgets

f. "Rapid development is high quality."

1. to users whose work is waiting for the software

2. to marketers who want to colonize a market before the competitors can get in

g. "User-friendliness is high quality."

1. to users who spend 8 hours a day sitting in front of a screen using the software

2. to users who can't remember interface details from one use to the next

The Political Dilemma

Recognizing the relativity of quality often resolves the semantic dilemma. This is a monumental contribution, but it still does not resolve the political dilemma:

More quality for one person may mean less quality for another.

For instance, if our goal were "total quality," we'd have to do a summation over all relevant people. Thus, this "total quality" effort would have to start with a comprehensive requirements process that identifies and involves all relevant people. Then, for each design, for each software engineering approach, we would have to assign a quality measure for each person. Summing these measures would then yield the total quality for each different approach.

In practice, of course, no software development project ever uses such an elaborate process. Instead, most people are eliminated by a prior process that decides:

Whose opinion of quality is to count when making decisions?

For instance, the project manager at MiniCozy decided, without hearing arguments from Terra, that her opinion carried minuscule weight in his "software engineering" decision. From this case, we see that software engineering is not a democratic business. Nor, unfortunately, is it a rational business, for these decisions about "who counts" are generally made on an emotional basis.

Quality Is Value To Some Person

The political/emotional dimension of quality is made evident by a somewhat different definition of quality. The idea of "requirements" is a bit too innocent to be useful in this early stage, because it says nothing about whose requirements count the most. A more workable definition would be this:

"Quality is value to some person."

By "value," I mean, "What are people willing to pay (do) to have their requirements met." Suppose, for instance, that Terra were not my niece, but the niece of the president of the MiniCozy Software Company. Knowing MiniCozy's president's reputation for impulsive emotional action, the project manager might have defined "quality" of the word processor differently. In that case, Terra's opinion would have been given high weight in the decision about which faults to repair.

The Impact on Agile Practices

In short, the definition of "quality" is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another. Of course, much of the time these political/emotional decisions–like all important political/emotional decisions–are hidden from public view. Most of us software people like to appear rational. That's why very few people appreciate the impact of this definition of quality on the Agile approaches.

What makes our task even more difficult is that most of the time these decisions are hidden even from the conscious minds of the persons who make them. That's why one of the most important actions of an Agile team is bringing such decisions into consciousness, if not always into public awareness. And that's why development teams working with an open process (like Agile) are more likely to arrive at a more sensible definition of quality than one developer working alone. To me, I don't consider Agile any team with even one secret component.

Customer support is another emphasis in Agile processes, and this definition of quality guides the selection of the "customers." To put it succinctly, the "customer" must actively represent all of the significant definitions of "quality." Any missing component of quality may very likely lead to a product that's deficient in that aspect of quality. As a consultant to supposedly Agile teams, I always examine whether or not they have active participation of a suitable representation of diverse views of their product's quality. If they tell me, "We can be more agile if we don't have to bother satisfying so many people, then they may indeed by agile, but they're definitely not Agile.

I am a music box.

Though I embody the finest science and craft, made entirely by hand, I exist only to create beauty and pleasure.

I can be played closed, as a mystery.

I can be played open, when every part is open for inspection.

Yet though every part can be seen, I cannot be understood as a mechanical object.
I need the touch of human fingers to wind me with energy, adjust my gears, and start my music.

Without human contact, I am merely a lifeless decoration.

Mistakes that Win

We all make mistakes.

We all try to eliminate mistakes.

But sometimes, mistakes are our best friends.

One of most common mistakes is arrogance—the belief that we know what we're doing. When we're arrogant, we think our knowledge is complete—particularly in our own work.

Here's an example. Johanna Rothman asked me to write a foreword for her terrific book, Hiring the Best. As I read the book, I realized that Johanna had made a horrible mistake in marketing the book. She said the book was for managers who do the hiring, but what she failed to see about her own work was an even bigger audience: people trying to be hired. Fortunately, that mistake, that omission, could be easily corrected.

Of course, I never make such mistakes, right?

Wrong!

I recently began publishing a series of books on Experiential Learning. In response to the second volume, Jason Reid wrote the following letter:

I participated in PSL this past May. ... I recently had the opportunity to conduct "project debriefs" with several coworkers. We didn't have a standard at my company for how these meetings should run, so I was free to design the agendas. I don't recall what sparked the connection, but I eventually thought of your book, Experiential Learning 2: Invention, and of some of the knowledge invention activities we performed during PSL. I figured that those activities were designed to assist learning after hands-on experiences, and I thought, "What's more hands-on than actual work?" So I determined that my goal for the debriefs would be to help my coworkers learn from their experiences on their projects, and your book was a gold mine for questions to ask them.

Each meeting went very well and I enjoyed them immensely. I lost count of the number of times I heard, "That's a great question!" from the person I was helping. While the mechanics of the meetings were limited to one-on-one discussion, I look forward to incorporating more of the activities in your book into future debriefs.

I now have a bruise on my forehead, from slapping myself when I read Jason's letter. He had caught me making the same mistake I had caught Johanna making: underestimating the market for my own book.

Fortunately, from now on, I will remind people that Experiential Learning 2 : Invention is "a gold mine" of questions and exercises useful for conducting retrospectives. If that leads people to read the book, then I have managed to profit from a friend pointing out my arrogance and stupidity.

Are your friends helpful in this way?

Is it real or is it Agile? (Part 1)

Well, I'm writing my blog again, now that my book, Experiential Learning: Inventing, is now published on LeanPub.com. But after only one week, the feedback has started, and I feel a need to respond.

My friend and colleague, Markus Gaertner was the first to write, all the way from Germany:

"I just started reading your second book on Experiential Learning. One thing that confused me is in the chapter Design and Development Inventions where you make a positive reference to agile processes. This confused me since you usually write in a timeless manner, and I don't consider agile processes to be timeless in--say--20 years or so."

The passage in question read like this:

-----

Sometimes the specification turns on the meaning of a word, such as “support,” or “height.” The trouble is, you don’t know in advance which word it turns on ... that depends on the design possibilities. Therefore, an organization or process that discourages back-and-forth communication will generally do a poorer job of designing things. That’s one of the reasons agile processes can work so well.

-----

My first reaction to Markus's comment was that he was exactly right. My half-century of experience tells me that in 20 years, the "agile" craze will have petered out, just like so many before it--structured programming, HIPO, Nassi-Schneiderman charts, and dozens of others. So most readers in 2030 or so, won't even recognize the word "agile" as a code.

Yet forgetting the code doesn't mean that "agile" principles will have disappeared as good programming practices. I was specifically referring to two sentences from the Agile Manifesto (you know, that document that a dozen of the guys worked out a decade ago, without the help of any women):

1. "Business people and developers must work together daily throughout the project."

2. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

That's what I meant by "back-and-forth communication," and I believe those sentences will still describe effective programming practice a generation from now (as they did a generation ago, and two generations ago).

So Markus is right. There's no reason for me to date my book by using the code word, "agile." I published my Experiential Learning series with LeanPub.com so it could be a dynamic e-book, changing as the world changed and I learned to be smarter. So, I will update the next version with something like Markus's suggested wording:

"That's one of the reasons that software development works so well with bi-directional communication in place."

 (I'll also make a batch of changes suggested by Dani--who didn't even recognize the code word, "agile," in 2012--plus whatever other wisdom arrives from my readers.)

But, as usual, I'm not finished responding to Markus and Dani. In a later blog, I'm going to continue with some thoughts about what is "agile" really.

Experiential Learning vol 2: Inventing

Regular readers of this blog have probably noticed a reduction in my posting frequency in recent weeks. Perhaps you'll all forgive me when I tell you I've been distracted from blogging by finishing volume 2 of my Experiential Learning series, called Inventing or Invention, I can never remember which. Anyway, it says "invention" on the cover, and can be found here.

Anyway, it's about the part of experiential learning that comes after the experience--the part where we invent the learnings we've found during the experience. It's what converts an ordinary experience into a learning experience. If you're teaching experientially, you'll want to learn how to facilitate invention--but that's not all. The book is full of techniques I personally use to extract learnings from all my experiences, whether in a class or in life.

As we say in life-learning, "First you pay the tuition, then the learning is optional." If you want to take advantage of the learning you've paid for with your life, Experiential Learning: Volume 2, Invention is the book for you.

Shaping a Team

A Correspondent Writes

I have taken over a group of folks that I need to shape into a team. There are many issues including getting developers to write unit tests consistently, training my test engineers and deploying more test automation. More worrisome is that they do not want to change out of a poor pattern of behaviors. I suppose since they hit their delivery schedule they think things are OK. On the plus side, they say they are committed to quality.

What would you look more into? Tackle first? Is there an inspiring story I might share at my upcoming team building event to highlight the need to change?

Any advice is welcome and greatly appreciated.

Jerry Replies

Well, you're certainly experiencing a classical problem, one I've described in a number of places, including my Becoming a Technical Leader (in terms of my pinball expertise). They're stuck on a plateau, and it's going to take some skilled leadership to move them up to the next level.

The first thing you have to do is create a safe environment that will protect them while they are changing to new practices. Although those practices must be designed to improve the quality of their work, there is no doubt that at first they will slow them down and probably hurt quality. That's why they need protection.

Start small, with some step that ideally they will choose from a list you develop together. Choose something that's as sure to succeed as possible, and it will help them in some obvious way. In other words, you want to start with a guaranteed success, and then build up from there.

 Beyond that, I suggest you read my books on change

- BECOMING A CHANGE ARTIST

- CHANGE: Planned & Unplanned

- Change Done Well

Writers Need Feedback

I recently received an email containing the following paragraph:

"A tester peer of mine here in town recently told me a great story of how your book, Perfect Software, helped save one of his tester's jobs. He gave the book to his Manager and it changed the manager's mind about testing and the need for good testers. I've encouraged my peer to contact you with the story in more detail and will keep doing that."

I love to hear stories of how my writing is influencing real people to change their world (for the better, I hope). I specifically intended Perfect Software and Other Illusions about Testing for the purpose of educating managers and others who require a better understanding of software testing if they are to do a better job.

Do You Have a Story?

I'd love to hear your story of how one of my writings helped you do a better job. I'd even like to hear your story of how one of my writings led you to do a worse job. I need this kind of feedback if I'm to do a better job myself.

In fact, I'd even like to hear stories about how other authors' writings helped or hindered your work. Or, even better, about writings that helped improve your life. Or made it worse.

I suppose I should give an example. Okay, like many smart people, I used to use my intelligence to think of reasons I should be miserable. That kind of thinking made me a rather miserable person. Then I read Bertrand Russell's little book, The Conquest of Happiness. Russell's words showed me that I could use my intelligence to be happy, not miserable. They changed my life.

They say that the pen is mightier than the sword. Well, we don't use pens much any more (or swords, for that matter), but there's still plenty of power in our keyboards. With all that power, we need to know if we're using it to people stronger or to lop off their heads.

So, let me hear from you, and I'll try to pass your feedback on to the whole world of writers.

Regular readers of this blog may have noticed that I slow down from time to time, which may signify that either (a) I'm sick or (b) I'm finishing a project. This time, it was a bit of both: (a) when I fell on my head and (b) when I was finishing a new book—Experiential Learning: Beginning.

If you are a writer, you may find my publication method interesting: LeanPub.com.

Those of you who teach should find my newest book interesting.

The Title is Experiential Learning: Beginning.

Experiential Learning the first volume in a series that collects and organizes more than fifty years of experience by many learning leaders using the experiential method to aid students in a variety of subjects, including, at least the following subjects:

* software development

* software testing

* anthropology

* physics

* writing

* design

* project management

* education

* medicine

* business administration

* architecture

* biology

* chemistry

* communication

* economics

* environmental science

* family therapy

* computer science

Where Can The Series Be Helpful?

At present, the Experiential Learning series is planned for three volumes. The first volume—Beginning—concerns getting started: starting using the experiential method, starting to design exercises, and getting a particular exercise off to a good start.

It should be particularly helpful for short classes—a day or two, or even an hour or two—though it could be for starting to use experiential parts of a longer workshop consisting of both short and long experiential pieces as well as more traditional learning models.

The second volume—Class—guides the reader in constructing,  delivering, and—most importantly—debriefing classes consisting entirely (or almost entirely) of one or more experiential exercises.

Volume Three—Simulations—takes up the possibilities for longer classes and longer exercises.

What Can Be Learned from the Series?

At the beginning of our classes, we generally gather the students' hopes for what will happen as a result of the class. (You can read more about this practice in the section called Requirements Gathering.) We haven't figured out how to gather requirements from each reader of a book, but we do offer a class about experiential learning, and from the participants in these classes, we've developed some ideas of what most of our students want.

So, what can you hope to gain from reading these volumes? We've made a list of hopes distilled from these classes:

• Learn practical knowledge about designing experiential exercises.
• Expand my understanding of what participants experience during experiential exercises.
• Unlearn things that interfere with effective experiential learning.
• Help to expand my "big picture" about this topic.
• Link to other knowledge to help increase my effectiveness.
• Figure out if students are really learning.

We've used this list to guide us in deciding what to include, and as with any experiential exercise, this book may lead its readers to many additional lessons we never planned for them.

Experiential Exercises

In the final analysis, a book about the effectiveness of experiential exercises may seem to be a paradox, but there's a learning there, too.

We are not claiming that the experiential method is the only way to learn. We're not even claiming that experiential exercises always teach anything worthwhile, or that students never take away erroneous or vacuous learnings. We're merely saying that we have found this approach to be one more tool for our teaching repertoire—a tool that has been strikingly effective for us as both teachers and learners. We hope it turns out that way for you, as well.

Mahlberg Interview

As promised, here's the rest of Michael Mahlberg's interview:

Michael: One of your books that comes to mind after experiencing the learnings of the AYE is titled The Psychology of Computer Programming.  How do you see the role of psychology in todays software industry?

Jerry: Quite simple, software is an industry based on mental processes, not physical ones. Our products are not made of metal or plastic, but are entirely mental constructs. Psychology is the study of our "production facility"--our brains. How we think and feel form the only true "software science."

Michael: You have written non-fiction books for decades and in this century you have started to write more fiction than non-fiction - what is the appeal of writing fiction for you?

Jerry: I see fiction as a natural extension of all my work. Stories allow me to create appealing and memorable lessons about life in general, but software thinking in particular. For many readers, stories are the best way to learn, other than through expensive personal life lessons (which often don't teach anything because they're too entangled with personal life issues. Fiction stories give some readers the "distance" they need to see the lessons, while offering the "closeness" to make the reading simulate true life. 

Also, for me personally, fiction writing is a new challenge, the kind of challenge I've always sought to further my lifelong learning.

Michael: In the early days of your career computers and software were used only on very few, very special projects - the Mercury Project, where you played a vital role, comes to mind - whereas nowadays computers are everywhere and even for the most mundane tasks software gets written. How would you say that this has changed the way our profession is conducted?

Jerry: First of all, nowadays, 99% of software developers are not "professionals." Still, the remaining 1% constitue a far larger population of professionals than we had when I started, more than 50 years ago. Those days, I basically knew every software pro in the USA, if not the world. So, the larger group of professionals gives us the opportunity to create a much more powerful community for learning and sharing (as long as we are able to distinguish the professionals from the amateurs).

Michael: Between writing novels, preparing conferences, conducting workshops - do you still find time to do consulting work? And if so, could you tell us a bit about current trends in software development as you perceive them in your consulting work?

Jerry: Consulting is the essential third leg of my business. From consulting, I learn what is really going on among the best organizations (the worst would never voluntarily hire a consultant, though I've met a few who were involved in non-performance lawsuits). From my consulting, I learn what I should be teaching (the second leg). And, through my teaching, I learn how to offer the significant lessons in the most effective way, and these ways are what leads to my books.

As far as current trends are concerned, I'm not too interested. Why? Because "current trends" have almost always turned into fads. What I seek is clients who are actually using some of the important things we've learned in the past 50 years. There aren't many of those, but the organizations who do them (rather than talk about the latest fads), are consistently the best.

Michael: Thank you very much for this interview!

Jerry: And thanks for the great questions. You've done a great job, Michael.

------------------- end of interview ----------------------------------

Why so successful and durable?

At November's AYE Conference, participant Michael Mahlberg asked if he could interview me for a German magazine. The interview and his article about AYE have now been published, but in German, so I thought I'd make the English version available to my readers whose German language skills are no better than mine. It's a long interview, so I'll probably use several blog entries to cover it all.

Michael: I thank you very much that you take the time for this Interview. You just came back from the 12th AYE - Amplifying Your Effectiveness - conference if I have counted correctly. 

Looking back on twelve years of AYE Conferences, why do you think that this unusual format proved so successful and durable?

Jerry: Several reasons come to mind, in no particular order:

1. We designed the conference in reaction to a number of conferences we hosts had just attended. We kept what we thought was good (such as, a few interactive sessions; some rare meal-time interaction;  comfortable accommodations) 

2. We discarded what we thought was bad (such as: overcrowding that really eliminated participant-participant interaction; segregation of presenters from participants; non-interactive presentations, such as power-point reading by presenters; a few big-name presenters who thought they knew all there was to know; amateur presenters who simply didn't know how to handle crowds [which were too big, anyway]; expensive accommodations; irrelevant activities such as nightclub events, stand-up comedians, shopping trips; third-party event planners who did not know the audience and/or topics).

3. We limited participation to 75, which after experimentation proved to be a number that kept down overcrowding and maximized interaction opportunities, while providing sufficient energy to run all sorts of experiential sessions.

4. We forbade power-point altogether, and required every session to be experiential.

5. We trained ourselves to be good designers and presenters of experiential sessions.

6. We kept prices low so independents would be able to come and add their viewpoint to the interactions.

7. We were not trying to make a pile of money, but instead were attempting to show what a conference would be like if we shed all the commercialism that has crept ahead of the espoused purposes of other conferences.

All in all, we've tried to do unto others as we would have others do unto us—and not just "unto" others, but with the full participation of others.

________________end of first question–––––––––––

Note: The 2012 AYE Conference will be held in Raleigh, North Carolina, Sunday, November 4 through Thursday November 8, 2012. You can read details at http://www.ayeconference.com

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.)

Figure 27 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. 

Figure 27. 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, Figure 28 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.

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

Source

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

The Order of Maria Theresa

Today's idea is embodied in a medal established in Austria. According to Wikipedia, the military order of Maria Theresa. "It was specifically given for 'successful military acts of essential impact to a campaign that were undertaken on [the officer's] own initiative, and might have been omitted by an honorable officer without reproach.' This gave rise to a popular myth that it was awarded for (successfully) acting against an explicit order."

The Order of Maria Theresa is a marvel of bureaucratic invention, but it's not unique. Every successful organization—nation, business, or neighborhood kite club—has rules for breaking its own rules. The only unusual aspect of the Order of Maria Theresa is that the rule was written down and officially recognized.

When Jefferson was drafting the United States Constitution, he naturally wrote an article concerning amendments. But when asked to write something granting the people the right to throw out the Constitution entirely and start afresh, Jefferson refused. He argued—correctly, I think—that the people had such a right whether or not it was written in the Constitution. It was a right superseding any government and any written rules of government. It was, in effect, a tautology, for without the consent of the governed, there is no government. A shadow, perhaps, but no government.

The same is true in any modern bureaucracy. Rules are not made to be broken, but neither are they made to be not broken. Rules are made so that the organization operates more effectively. The rule above all other rules is "Do what is necessary to operate effectively." You ultimately get punished for not operating effectively, but not for breaking the rules.

It seems to me the problem with bureaucracies is this: the obverse side of this coin isn't so shiny. If you obey the rules and things turn out badly, you don't get punished. In war, the problem may be easier, because if things turn out badly you may be dead and not have to face the Empress. In the XYZ Pork and Bean Factory, your life is not usually at risk—even if your customers are taking their lives in their hands every time they pick up a pork fork.

I'd be interested in pursuing the biographies of Maria Theresa winners after they won the medal. I know that in the United States—where the Medal of Honor is often given under similar circumstances—many winners wind up, as civilians, trying to get a few cents for their medals in a pawn shop. Even medal-winning is a short-lived glory in the best of circumstances.

When I started to write this essay, I hoped to conclude by recommending each organization install an Order of Maria Theresa to counteract the conformist tendencies infecting even the best-managed organizations. But as my thoughts developed, I realized medals are not the answer. If you're on top of a large organizational pyramid and want protection from your own mistaken orders, you're going to have to work harder than Maria Theresa.

You can start by ensuring nobody is punished merely for discussing the merits of a particular order of yours. Even if you don't punish discussion, you'll need a long time to overcome the fears people have learned throughout their long careers in other organizations. But the long wait will be worth it, for then you will be relieved of the burden of perfection—a burden no person and no nation can long endure.

You might think your next step would be to encourage people to disobey orders they think are wrong or foolish, but they won't need any encouragement if the climate for talking is right. At least some of them won't, and the others will be watching to see what happens to the pioneers. 

So your second problem comes when someone disobeys—and fails! Now you have the perfect opportunity to play "I told you so," but if you do, there won't be any further games. Instead, you must convince the person to tell you why the order was disobeyed. It might have been a stupid order, destined to fail even if it had been carried out. Or it might have been misunderstood—a most likely alternative.

And once you've understood the reasons for the disobedience, drop the whole matter! Everyone is entitled to make a mistake now and then. If people never make mistakes, it means they're never trying and never thinking, which is the most horrible fate a bureaucracy can contemplate. Only if the same person disobeys orders over and over will you have to take any action—and by then your course of action should be obvious.

But won't the repeated failures create a disaster? Perhaps, but then you can take comfort from the Austrian motto: The situation is hopeless but not serious.

In the programming business, we have the comfort of a large cushion of safety in what we do. We make many mistakes, but we have procedures designed to detect them and remove them before they cause too much harm. If those procedures are working well, it gives us some breathing room in which to make mistakes—the same room we need in order to learn. In such situations, we shouldn't need medals to keep us disobeying foolish orders.

This essay is adapted from a chapter in the book, Understanding the Professional Programmer. The book is actually a series of such essays, all aimed at the often difficult task mentioned in the title.

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