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.