New: #System #Design #Heuristics

You'd think that after publishing books for half a century, I'd know how to write a book. If that's what you think, you'd be wrong.

Sure, I've even written a book on writing books (Weinberg on Writing, the Fieldstone Method), and I've applied those methods to dozens of successful books. But way back around 1960, I started collecting notes on the process of design, thinking I would shortly gather them into a book. Back then, I didn't call these bits and pieces "fieldstones," but that's what they turned out to be: the pieces that, when assembled properly, would ultimately become my design book.

Ultimately? Assembled properly? Aye, there's the rub!

Building walls from randomly found fieldstones requires patience. So does writing books by the Fieldstone Method. My Introduction to General Systems Thinking took fourteen years to write. But a writer only lives one lifetime, so there's a limit to patience. I'm growing old, and I'm beginning to think that fifty years is as close to "ultimately" as I'm going to get.

So, I've begun to tackle the task of properly assembling my collection of design fieldstones. Unfortunately, it's a much larger collection that I'd ever tackled before. My Mac tells me I have more than 36,000,000 digitized bytes of notes. My filing cabinets told me I had more than twenty-five pounds of paper notes, but I've managed to digitize some of them and discard others, so there's only a bit more than ten pounds left to consider.

For the past couple of years, I've periodically perused these fieldstones and tried to assemble them "properly." I just can't seem to do it. I'm stuck.

Some writers would say I am suffering from "writer's block," but I believe "writer's block" is a myth. I've published three other books in these frustrating years, so I can't be "blocked" as a writer, but just over this specific design book. You can hear me talk more about the Writer's Block myth on YouTube 

[https://www.youtube.com/watch?v=77xrdj9YH3M&t=7s]

but the short version is that "blocking" is simply a lack of ideas about how to write. I finally decided to take my own advice and conjure up some new ideas about how to write this design book.

Why I Was Stuck

To properly assemble a fieldstone pile, I always need an "organizing principle." For instance, my recent book, Do You Want to Be a (Better) Manager? is organized around the principle of better management. Or, for my book, Errors, the principle is actually the title.  So, I had been thinking the organizing principle for a book on design ought to be Design. 

Well, that seemed simple enough, but there was a problem. Everybody seemed to know what design is, but nobody seemed able to give a clear, consistent definition that covered all my notes. I finally came to the conclusion that's because "design" is not one thing, but many, many different things.

In the past, I ran a forum (SHAPE: Software as a Human Activity Practiced Effectively) whose members were among the most skilled software professionals in the world. We held a number of threads on the subject, "What is Design?" The result was several hundred pages of brilliant thoughts about design, all of which were correct in some context. But many of them were contradictory.

Some said design was a bottom-up process, but others asserted it was top-down. Still others talked about some kind of sideways process, and there were several of these. Some argued for an intuitive process, but others laid out an algorithmic, step-by-step process. There were many other variations: designs as imagined (intentional designs), designs as implemented, and designs as evolved in the world. All in all, there were simply too many organizing principles—certainly too many to compress into a title, let alone organize an entire book.

After two years of fumbling, I finally came up with an idea that couldn't have been implemented fifty years ago: the book will be composed of a variety of those consulting ideas that have been most helpful to my clients' designers. I will make no attempt (or very little) to organize them, but release them incrementally in an ever-growing ebook titled Design Heuristics.

How to Buy System Design Heuristics

My plan for offering the book is actually an old one, using a new technology. More than a century ago Charles Dickens released many of his immortal novels one chapter at a time in the weekly newspaper. Today, using the internet, I will release System Design Heuristics a single element at a time to subscribing readers.

To subscribe to the book, including all future additions, a reader will make a one-time payment. The price will be quite low when the collection is small, but will grow as the collection grows. That way, early subscribers will receive a bargain in compensation for the risk of an unknown future. Hopefully, however, even the small first collection will be worth the price. (If not, there will be a full money-back guarantee.)

Good designs tend to have unexpected benefits. When I first thought of this design, I didn't realize that it would allow readers to contribute ideas that I might incorporate in each new release. Now I aware of that potential benefit, and look forward to it.

Before I upload the first increment of System Design Heuristics, I'll wait a short while for feedback on this idea from my readers. If you'd like to tell me something about the plan, email me or write a comment on this blog.

Thanks for listening. Tell me what you think.

A small problem-solving tip for your TO DO list

Here's a little principle for all TO DO and NOT TO DO lists. I suspect most of us do this instinctively, but it's worth making it an explicit part of your planning process:

Break the tasks into small tasks for scheduling purposes.

If you have large tasks to do, they may keep falling to the bottom of your stack because they look too imposing or because you rarely have large blocks of empty time.

Also, smaller tasks have fewer conditions needed to start. A large task may have so many pre-conditions that even when you have the time, one of the conditions may be missing, so you don't start. 

One way to break up a large task is to create smaller tasks, each one of which removes a pre-condition for the larger task. For example, if you need to call a source, but you do most of your work at a time when the source may not be available, make the call into one small task so it can be removed from the constraints on the large task.

Small tasks are also motivating because you receive frequent feelings of accomplishment.

https://leanpub.com/areyourlightson

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.

Change Artist Challenge #5: Being The Catalyst

Look abroad thro' Nature's range.
Nature's mighty law is change. - Robert Burns

Although change artists often work as prime movers, they more often work through understanding natural forces and creating slight perturbations of Nature. In this challenge, you will practice facilitating the change projects of others, using various ways of empowering from the position of catalyst. In chemistry, a catalyst is a substance that added to a reaction accelerates that reaction by its presence, without itself being changed by the reaction.

A human catalyst is someone who rouses the mind or spirits or incites others to activity with a minimum of self-involvement—in other words, by empowering others. For people to be empowered to change their organization, the MOI model tells us that the following ingredients are required:


Motivation
• self-esteem
• a value system and a vision held in common
• a sense of difference between perceived and desired

Organization
• mutuality of support, based on personal uniqueness
• a plan for reducing the perceived-desired difference
• a diversity of resources relevant to the plan


Information
• a systems understanding of what keeps things from changing
• an understanding of empowerment versus powerlessness
• continuing education appropriate to the tasks

Often, only a single ingredient is missing, but the person who doesn't know which one it is can feel completely disempowered. The recipe suggests which ingredient might be missing. A change artist who supplies that missing ingredient can catalyze change with minimal effort.


The Challenge

Your challenge is to facilitate other people's change projects, approximately one per week, for at least two weeks. You should attempt to be a catalyst, for change, not the prime mover for change. To be a catalyst, you should involve yourself

• as effectively as possible

• in the smallest possible way

• without depleting your capacity to catalyze other changes

If possible, use each ingredient of this recipe for empowerment at least once. Keep notes in your journal and be prepared to share learnings with the group you are catalyzing.

Experiences
1. A group in the shipping department asked me to help them run their planning meetings. I said I would do it if they enrolled two people in our facilitation class, and that after taking the class, they would work alongside me. After one meeting, they are now facilitating their own.

2. I led a technical review of the design of a very controversial project, and apparently I did a good job because I got three other invitations to lead difficult reviews. I did lead two of them, but I decided to try being a catalyst on the third. I told them I wouldn't lead the meeting, but I would play shadow to a leader of their choice and we would switch roles if their leader got in trouble. She didn't.

3. One of my groups wasn't using—or even attempting to use—the new configuration control system. Ordinarily, I would have ordered them to use it, with threats of reprisals. I thought about the minimum thing I could do—with no force and no blaming—to get them moving. I decided to call them in for a meeting and give them the problem of how to get them moving. They told me they just didn't have time to switch their partially developed project to the new system. I asked them how much time they would need. They huddled and came up with a two-week extension to their schedule. (I had been afraid they would say two months.) Since they were off the critical path, I said they could have the two weeks, but only if they switched to the new system. They actually did the job in one week, and in the end, they made up four days of that—partly, at least, because of using the better tool. I've now used this consultation method several more times. "What would you need to give me what I need?" turns out to be a great catalyst. I like being a catalyst much more than being a dictator.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.