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.

Terchnical Reviews and Organizational Renewal

We know that success can breed failured and doesn't automatically renew itself. I would like to offer some ideas on how this self-defeating tendency can be resisted.

One way toward renewal is through new perspectives gained from outside technical audits, but audits suffer from several serious disabilities. For one thing, audits are done intermittently. In between one audit and the next, the programmers don't stop programming, the analysts don't.stop analyzing, and the operators don't stop operating. Sometimes, though, the managers stop managing, And there's the rub.

A comparable situation exists when a firm has a system of personnel reviews mandated, say, every six months for each employee. Under such a system, managers tend to postpone difficult interactions with an employee until the next appraisal is forced upon them. A huge dossier may be accumulated, but then ignored in favor of the last, most conspicuous blunder or triumph. Good managers realize that the scheduled personnel review is, at best, a backup device—to catch those situations in which day-to-day management is breaking down.

In the same way, the outside technical audit merely backs up the day-to-day technical renewal processes within the shop. It may prevent utter disasters, but it's much better if we can establish technical renewal on a more continuous and continuing basis. One way to do this is through a technical team, such as an Agile team. For now, though, I want to introduce, or reintroduce, the concept of formal and informal technical reviews as tools for renewing the technical organization.

The Agile Manifesto requires "technical excellence" and "simplicity," and states: 

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

To achieve these and other goals, Agile teams conduct "walkthroughs" and "inspections," but these are only two very specific examples of technical review procedures used by Agile teams. In my reading and consulting, I've uncovered dozens of major variants of these two types of review, plus literally hundreds of minor variants that shops have introduced to make the review more suitable to their environments, whether or not they claim to be "Agile."

A more general definition of a technical review could be 

1. a review of technical material on the basis of content (this is what makes it a "technical" review, rather than, say, a financial or personnel review)

2. which is done openly by at least two persons (this is what distinguishes it from "desk checking")

3. who take lull responsibility for the quality of the review (not, please note, for the quality of the product)

Then we distinguish between the informal and formal review. A formal review produces a written report to management. That report is the formal part.

Informal reviews (that is, reviews which need not terminate with a written report to management) are also excellent devices for an organization's self-renewal. Informal reviews take all forms of technical reviews, and are practiced everywhere almost all the time. Indeed, they are an essential part  of the real world of programming work.

For instance, a team member passes a diagram to a teammate for an opinion on how to represent a particular design. Someone asks help from someone else in finding an error. A set of test cases is passed around to see if anyone can think of something that's been overlooked. One person reads another's user document to see if it's understandable.

Without a constant flow of such informal reviewing of one another's work, programming any meaningful project would be impossible. Formal reviewing, on the other hand, is not essential to programming. Many small projects are accomplished without formal reviewing, which is why some programmers don't appreciate the need for formal reviewing. 

As projects grow 'larger and more complex—as they are inclined to do in successful shops—the work of many people must be coordinated over a long period of

time. Such coordination requires management—though not necessarily managers—and such management requires reliable information. Formal reviews, essentially, are designed to provide reliable information about technical matters—particularly to non-technical people.

Clearly, a successful system of formal technical reviews—that is, a system that provides management with reliable information on technical matters—is essential to management participation in the organizational-renewal process. For the large shop, formal reviews provide information that the small shop manager gets "through the seat of the pants." Many, many failures of previously successful programming organizations an be traced directly to the breakdown of the earlier informal mechanisms for communicating reliable information about technical matters.

There may, of course, be other ways of getting this kind of information, and many smaller shops do an excellent job without any system of formal reviews. Even those shops, however, may benefit from an explicit system of reviews to supplement their implicit, or informal, existing system. 

Principally, the formal technical review provides reliable self-monitoring. An informal system may work just as well as a formal one, and if so, there are many reasons to prefer to keep the reviewing informal. In any case, there will always be an informal system at least supplementing the formal one, but we should really view the formal system as supplementing the informal. Its formality guards against creeping deterioration of the organization.

Regular reviews of specifications, designs, code, test plans, documentation, training materials, and other technical matter have many beneficial "side effects" on the health and success of an installation. Reviews have a very marked effect on maintenance—that quicksand in which a thousand successful shops have met an untimely end. A typical program that has been thoroughly reviewed during its development will

1. require less maintenance work per change

2. require fewer changes caused by poor specification, design, coding, or testing.

Instituting a program of technical reviews will not, of course, have any immediate effect on the existing burden of maintenance carried like an albatross from a sinful programming past. Indeed, when maintenance programmers participate in reviews of newer code, they may be further discouraged by the poor quality of the code with which they are burdened. But, the situation can improve rather quickly, for a variety of reasons:

1. Some new ideas can be applied even to patches to old programs, though naturally limited by poor existing structure and style.

2. Through mutual participation in reviews, the entire shop quickly obtains a realistic and sympathetic picture of the true dimensions of the maintenance situation.

3. The worst maintenance problems will, through frequent reviews, become exposed to fresh air and sunlight.

Quite frequently, installation of a review system is quickly followed by replacement of the most cantankerous old beasts left over from the Stone Age of Programming. The effect of even one such replacement on maintenance morale is a wonder to behold,

Other activities besides maintenance are similarly affected. In the long run, certainly, reviews have a remarkable effect on staff competence, perhaps the most important element in continuing success. We also see increased morale and professional attitude, reduced turnover, more reliable estimating and scheduling, and better appreciation of the management role in project success. (Usually, the technical staff has had no difficulty in appreciating the management role in project failure.)

At the same time, reviews provide management with a better appreciation for staff competence, both individually and collectively. The unsung hero who quietly saved a dozen shaky projects is now sung far and wide. The "genius programmer" who was always the darling of the executives has been exposed for the empty and obsolete shell the technical staff always knew, but couldn't expose to management.

No other factor is more depressing to a technical organization than misappraisal of technical competence by non-technical management. The openness of technical reviews marks an end to that misappraisal era. No longer will we all feel cheated by charlatans and incompetents.

As a consultant, I visited dozens of installations every year. The best way to summarize the effects of properly instituted reviews is to report that after five minutes in an installation, I can tell—without asking directly—to what extent there is an effective review-practice, formal or informal.

How do I tell? Metaphorically, I tell in the same way a government health inspector tells about a food processing plant—by the way it smells. It's hard to describe, but when you smell the difference, you-know it!

* * * * * *

Looking back over this essay, I sense its inadequacy to the task at hand. Those programmers and analysts who have experienced a shop with a properly functioning system of reviews will know all this without my giving any details. They've experienced it, and if they are professionals, they'll never agree to work in any other kind of environment.

But those who have never experienced such an environment of a self-renewing organization will not understand, or will misunderstand, what I've written. Some of them will have experienced a misguided attempt to institute reviews. Perhaps the attempt was in the form of a punitive management mandate. Perhaps it was merely a case of another programmer who read one article and blundered ahead with 99% enthusiasm and 1% information—and zero human feeling. To these people, the experience of "reviews" will have left a bitter taste, or a painful memory. They will not recognize their experience in what I've written.

In many ways, technical reviewing is like bicycling. Up until the time you first discover your balance in one miraculous instant, the whole idea seems impossible, contrary to nature, and a good way to break a leg. Indeed, if you'd never seen a cyclist before, and had the process described to you, you'd most certainly declare the whole procedure impossible. And, without instruction and encouragement from experienced cyclists, along with reliable "equipment," the most likely outcome would certainly be skinned knees, torn pants, and a few lumps on the head. And so it has been with technical reviews—until now—-so don't go off and try to learn the whole process on your own.

If you want to get started renewing the success of your own shop through a system of technical reviews, find an experienced shop, or a person from an experienced shop, to guide you. Listen to them, Read the literature. Then try a few simple reviews on an experimental basis, without much fanfare.

Adapt the "rules" to your own environment. Be forgiving and humane. Your rewards  will not be long in coming.

references: 

Handbook of Technical Reviews, 4th ed.

Do You Want To Be A (Better) Manager?

What's it like to rewrite a program from scratch?

This is an interesting question because so many programmers are so afraid of this task that they would never even ask it. Is this reluctance agile, or Agile?

But why would you want to do rewrite a program from scratch? The most important reason is to increase maintainability. In the initial writing, the focus is generally on merely getting the job done, without thinking of the program's future. Over their lifetime, many programs cost far more to maintain than to write originally, especially when the original program has become a thing of rags and patches.

A second, and often secondary reason to rewrite a program is efficiency. Newly constructed programs and highly patched old programs sometimes turn out to be slower than desired, but such inefficiency cannot erased by any amount of tweaking. Instead, increased efficiency requires a new approach, an approach that needs to be implemented from scratch.

But isn't rewriting expensive? Not usually. In fact, it’s generally far, far easier to rewrite a program from scratch than to write some brand-new program.

Why would a fresh start-over be cheaper than the original? Because in writing the original program, the original programmers answered so many difficult questions about what was really wanted. Requirements haven't changed, and most of the thought put into testing can be reused.

Those questions—requirements and test—usually make up more than half the total work put into a program. They have already been answered—but only if you resist the temptation to change those answers. If you don’t resist, then rewriting the program can be arbitrarily difficult.

I wish more programmers had to courage to rewrite some clumsy programs from scratch, rather than patch and patch and patch. And I wish their managers would encourage sensible rewriting, rather than force programmers to waste their skills, time, and energy keeping ancient programs on life support.

The Psychology of Computer Programming: Silver Anniversary eBook Edition 

Is Waterfall the Opposite of Agile?

Agilists sometimes behave unreasonably by pummeling the Waterfall approach. Personally, I think such evangelists could better spend their effort producing solid, relevant code, but evidently they are on a crusade and need an enemy. If they need an enemy of Agile, however, they could have made a better choice.

There's nothing wrong with the Waterfall approach—if applied appropriately. For Waterfall to work well, you need to solve a problem that's not destined to change much, or, ideally, to change not at all. Some Agilists claim there is no such unchanging problem, but they're merely showing their lack of experience. I've seen a number of such invariant problems, and they yield very readily to a properly applied Waterfall development.

For example, Erik, a former student of mine, made a lucrative business of converting COBOL programs to new COBOL programs adapted to new versions of the COBOL compiler. Erik's customers wanted assurance that nothing would be changed in the conversion. This was a perfect situation for a simple Waterfall approach, one that Erik could perform profitably at a fixed price and schedule.

That said, the number of such invariant problems is not large, and it's usually difficult to know at the beginning if a problem will turn out to be so stable. In Erik's case, some of his customers would decide midway that they wanted a few "tiny" improvements in the converted application. Erik controlled that situation by charging outrageous fees for even the simplest modification. Most of us, however, try to control this situation by employing some Agile approach.

Let's be honest with ourselves: one consequence of an Agile approach is the loss of our ability to work to a fixed cost on a fixed schedule. Erik could do that, but only in a few carefully controlled situations. Many managers frustrate themselves over this lack of control and blame it on Agile. What's really to blame, however, is their inability to control the world in which they live. Things do change, and much of the time it's these very managers who instigate the change.

What do frustrated managers do? Quite often, they elevate their attempts to control the change by making rules. They may start using a pure Waterfall approach, but as their frustration with changes grows, they may add a Change Control Board, or change reviews, or a Change Tsar, or any of a number of other tactics. And, when those tactics fail to produce absolute predictability, they add more of the same kinds of rules and their supporting tactics.

After a while, these rules upon rules produce an approach that, though called "Waterfall," is actually something quite different—something for which we so far have no accurate name. This "something" is what Agile is responding to, so I suggest we name it.

What are these cobbled-together approaches like? First of all, they create a sad and dismal mood among those poor developers condemned to use them. When I visit a new client, I can generally detect the use of such an approach while I take a stroll through of the premises. I can even detect such approaches over the phone. How? Simple: the mood of my clients is mournful, gloomy, sad, unhappy, doleful, glum, melancholy, woeful, miserable, woebegone, forlorn, somber, solemn, serious, sorrowful, morose, dour, cheerless, joyless, and dismal.

That's quite a sobering list of adjectives, but that's what I can sense in many so-called "Waterfall" environments. Perhaps you recognize the list, but in any case, you can find that list in your dictionary as synonyms for the rare word, "lugubrious."

Perhaps the word "lugubrious" is unfamiliar, but that's good, because we won't often find it used in other contexts. Besides, it's a rather onomatopoetic word—a word that phonetically imitates, resembles or suggests the source of the sound or situation it describes. That's why Agile was invented—to replace those mournful, gloomy, rule-dominated approaches with brain-driven judgments of the actual builders.

So let's be truly Agile and stop bashing the true Waterfall approach. Instead, let's turn our contempt on every Lugubrious approach—or, to make a noun from the adjective, Lugubriousity. Maybe this more accurate name will help us defend our Agile projects from frustrated managers' attempts to smother us with yet more rules.

Or, to paraphrase DeMorgan, who in turn paraphrased Swift:

Great rules have little rules upon their backs to spite 'em,

And little rules have lesser rules, and so ad infinitum.

Never forget that's why we do Agile, not to dry out Waterfalls but to defeat Lugubriosity.

For more thoughs on the Agile approach, see

Agile Impressions

Tiips on writing your first book

I was asked, "What tips can you give to someone who wants to write his first book?"

Don’t worry about it, because the first book is just practice.

Maybe the first few books.

So stop worrying and write your practice book.

If your first book happens to be a success, that’s gravy. You can control whether you win or lose, but you can control whether or not you learn.

Get the book out there and gather feedback. Then use that feedback to improve your writing for the next book Repeat this process a few times and you’ll become a successful writer.

Do you recognize this iterative development process? You should, because writing a successful book is very much like writing a successful program.

In the meantime, if you'd like some help getting that first book finished, read

Weinberg on Writing: The Fieldstone Method

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

How can I be a faster programmer?

Recently, "Tommy" posted the following question on Quora, a question-answer site with lots of good stuff (and some really cheesy stuff) on a variety of topics:

How can be a faster programmer?

Tommy received a goodly portion of excellent answers, with lots of details of tips and techniques—great stuff. Reading them over, I saw that a few of the answers offered some good high-level advice, too, but that advice might be lost in all the details, so I decided to offer a summary high-level view of what I've learned about speedy programming in my 60+ years in the computer business.

First of all, read all the great answers here on Quora and incorporate these ideas, one at a time, into you programming practices. In other words, to become faster or better in some other way, KEEP LEARNING. That’s the number one way to become faster, if you want to be fast.

Second, ask yourself, with each job, “Why is programming speed so important for this job?” Often, it’s an unskilled manager who knows only a dangerous amount about programming, but can always say “work faster.” So ask yourself, what’s an appropriate speed for this job, given that speed and error are tightly related.

Third, ask yourself, “Do I really need a program for this problem?” If you don’t have to write a program at all, that gives you infinite speed. Sometimes you don’t have to write a program because one already exists that will do an adequate job. Sometimes you don’t have to write a program because a back-of-the-envelope estimate will give all the answers needed. Sometimes you don’t have to write a program because there’s no real need for the function you’ve been asked to implement.

Fourth, don’t skimp on up front work because you’re rushing to produce code. If you’re working with the wrong requirements, any nifty code you write will be worthless, so any time you spend on it will be wasted. If your design is poor, you’ll write lots of wasted code, which means more wasted time.

Fifth, when you finally have a good design for the right requirements, slow down your coding in order to go faster. We say, “Code in haste; debug at leisure.” Take whatever time you need to think clearly, to review with your colleagues, to find solid code you can reuse, to test as you build incrementally so you don’t have to backtrack.

Sixth, develop in a team, and develop your team. If you think teammates slow you down, then it’s because you haven’t put the effort into building your team. So, in fact, we’re back to the first point, but now at the team level. Keep learning as a team. Your first job is not to build code, but to build the team that builds code.

Many of these principles are developed in much more detail in my many books on software development, so if you want to learn more, take a look at my Leanpub.com author page and make some choices among about fifty books and a bundle of bundles of books. Good reading!

How Culture Brokers Make Software Successful

Perhaps if I'd been using my fourth-generation Executive Time Management software package, the mistake never would have happened. But I couldn't even get the darn thing loaded, so I put the manual in my bottom drawer and fell back to my zeroth generation paper and pencil calendar. And somehow I managed to schedule, two lunch appointments for the same day.

Jake, who was IT manager at Ninth National Bank, suggested that we all have lunch together. And that, because of my mistake, I should pay for the lunch. My stupidity had left me with no good alternative.

I called Lorene at the IT section of Glittering Mines. She agreed to the lunch å trois—at an appropriately expensive French restaurant. It was going to be an expensive mistake.

After lunch, emboldened by a stomach full of lemon sole, I decided to talk about the software difficulties that engendered this situation.

Jake was immediately sympathetic: "You're not the only one who has trouble with so-called fourth generation software. I've spent $75,000 for a 'user-friendly' financial analysis package. It's so unfriendly that all the users cursed me for buying it."

"You obviously bought the wrong package," Lorene said. "For the same price, we got a financial analysis package that really is user-friendly. Our users love it, and they love us for buying it for them."

"What package is it, Lorene? Perhaps Jake could get a trade-in."

"It's called MONEYPENNY—"

"...but that's the stupid package we-bought!" Jake roared. "Your users must be a lot smarter than ours."

Lorene looked puzzled. "If you knew our users, you wouldn't say that. Maybe you got a different version of the system."

"Ours is version 3.12."

"So is ours. I don't understand it."

While Jake and Lorene ran through several other possible differences, I looked for loophole in the lunch bill. I couldn't see any way out of the bill, but I did see an opportunity to earn it back.

"I have an idea," I volunteered. "Perhaps there's something  different in the way you two managed the introduction of the package. If you're interested, I can tackle the question as an add-on to my consulting contracts."

After a short negotiation, we agreed that I would interview a few users in each organization, as long as it didn't add anything to their costs. If I found anything interesting, then it night lead to future contracts.

At Ninth National, however, the users taught me nothing except a few new swear words. At Glittering Metals, the users were less emotional, but I didn't learn anything at all.

I decided I must have been mistaken. Something about MONEYPENNY made it more usable at one place than another. I asked Cliff, the last user I interviewed, if he'd let me watch him use MONEYPENNY. I promised to sit next to him and say nothing, regardless of what happened.

It seemed MONEYPENNY was an average "fourth generation" package. It had some nice features, but it didn't meet my human engineering standards. Still, Cliff seemed to be getting along all right... until the screen flashed this ominous message:

ILLEGAL ENTRY... COMMAND REJECTED

Cliff pondered the message for a few moments, then hit a few keys. Another message:

RECURSION ATTEMPTED IN PARAMETER

"What's recursion?" Cliff asked.

"It would be better if I remained an observer," I said, a bit cowardly. Just do whatever you would do naturally."

"Well, at least tell me what's parameter."

"Don't be angry, but I promised not to say anything."

"Okay, then call the Hot Line. Scott or Leatrice should still be there. They usually work late."

"Who are Scott and Leatrice?"

"They're the Hot Line Programmers for MONEYPENNY. Who did you think I would call?"

Being a good consultant, I played it cool. "Oh, the Hot Line Programmers, of course. I just didn't know their names."

Cliff talked to Leatrice, who gave him a magic formula to put the hex on his unwanted recursion. The hex worked, unlocking the screen and sending Cliff merrily on his way. After the session, I asked him if he ever had any trouble with MONEYPENNY.

"Trouble? No, nothing that I couldn't handle. It's a real user-friendly system. "

Cliff never mentioned Scott or Leatrice, but I thought I'd pay a visit to the other end of the Hot Line.

It turned out that the Hot Line is an institution at Glittering Metals, dating back to the dawn of punched card tabulating equipment.

"Programmers serve on the Hot Line mostly when they're between projects," Leatrice told me. "It's good experience—you never know what you'll get into."

"What kinds of things?"

"Everything and anything, I suppose."

"That's not very helpful. Don't you have a job description?"

"Not really. It's kind of a temporary assignment, so you just keep your old job category. I'm a Senior Programmer, but we have Systems Analysts, too. And one Systems Programmer."

Later, Lorene told me that the job of people on the Hot Line is to  do whatever is necessary to make users happy. In the old days that might have meant running off an extra copy of some report they had lost and carrying it upstairs to them. Now it frequently meant figuring out how to get their user-friendly systems talking to them again. •

"It sounds to me like a Hot Seat, rather than a Hot Line. What kind of people do you put in that job?"

Lorene pondered my question for a few minutes before answering. "I guess I look for generalists—people who can do a little bit of everything. They've got to be technical enough not to be snowed by systems problems, but they've got to be good communicators—good listeners especially—above all else. Not many of our technical people are good listeners."

"What else?"

"Well, they're problem-solvers. They don't get stuck. Somehow they get things going."

Having concluded my investigation, I went back to Ninth National. I explored the question with Jake, but he said they had nothing like the Hot Line. I then asked him if they had any user-friendly packages that had worked well.

"Sure," he said without hesitation. "There's a statistical analysis package that they use in Personnel They've never had a moment's trouble with it—but they certainly don't have a Hot Line."

I arranged to visit Personnel, where I soon discovered that their "Hot Line" was Arlo, a Senior Records Clerk who had learned to use the statistical package when he did a Master's thesis in Personnel Management. Arlo was the one who had suggested the package in the first place, and he was a gold mine of miscellaneous information about how to make it work.

Arlo wasn't part of the IT department, so Jake didn't even know of his existence. All the same, Arlo seemed to be the critical difference between success and failure of the statistical package.

When I returned from the trip, I discussed these events with Dani, my life partner and resident anthropologist. "What you seem to have discovered," she said, "Is what anthropologists call a cultural broker."

"Tell me more."

"Cultural brokers exist whenever two different cultures must interact in spite of their different languages, value systems, customs, and other barriers to communication. The cultural broker is a person who happens to have one foot in each culture, so can act as a go-between whenever the need arises."

I was impressed with the aptness of this description. Users often say that IT is a "different culture." IT-ers, on the other hand, certainly feel the same way about their customers and users.

A series of visits to other clients convinced me that behind every successful "user-friendly" system there were cultural brokers. Sometimes they were right out in the open. Sometimes they were so well hidden they almost blended into the wallpaper. But they were always there.

Once I became aware of this hidden function, I discovered cultural brokers under such titles as Customer Service Representative, User Service Specialist, Technical Specialist (with a variety of subtitles), Consultant (again with subtitles), and Systems Engineer.

And, since the advent of the Agile movement, I've found them operating openly as Customer Surrogates. The problem with this title, in my opinion, is that it suggests a one-way communication, ignoring the function of communicating with the customer about the culture of the Agile team. But such a hidden function is not exceptional. Most of the cultural brokers I've found are masquerading under conventional titles, including Programmer, Analyst, Systems Analyst, Systems Programmer, Trainer, Database Administrator, and Business Analyst.

Throughout my consulting career, whenever I find a successful system, I've hunted for the cultural brokers. Though they were called by different names, attached to different departments, and had different job descriptions, there were cultural brokers everywhere software systems were successful.

Here are just a few examples.

A large bank has a department staffed with "Technical Specialists." Organizationally, Information Center reports to the IT manager, but physically it is in a separate office close to the two major user groups.

The Technical Specialists support whatever packages are purchased for users with such activities as training new users, consulting on immediate problems, helping users write specs for add-ons, and negotiating fixes with vendors.

The IT manager says that the title "Technical Specialist" was purposely vague, so as not to prejudice anyone against doing anything necessary to get the users what they want. He says: "Sometimes they come over here and convince us to do things for the users that I can't believe I'm agreeing to. And I hold their pay checks!"

In the actuarial department of one insurance firm, buying software packages is an established practice. Whenever a new package is contemplated, one of the younger actuaries is assigned the job of making the selection, or deciding to build their own. Once a package is selected or built, the chooser becomes the cultural broker for that system—under the informal title of Technical Specialist for the XYZ System.

Glittering Metals had their Hot Line system, in which the cultural brokers were any technical people who happened to be under-loaded. In several other installations, essentially the same system was in place with no formal recognition from management. Users simply learned the name of someone in IT who "knew the answers," and that person's name got passed from user to user.

In another bank, the investment analysts were happily using a new system without any outside help. In fact, they were so happy with the system that they started to swamp the bank's on-line database. A database specialist who was sent upstairs to investigate discovered that their "programming" not only consumed their time but also produced many subtle bugs that invalidated their analyses.

The investment manager requested that the database specialist be permanently assigned to assist the analysts, thus creating a new cultural broker.

In the marketing department of an electronics manufacturer, their informal hot line system changed when the informal cultural broker departed for greener pastures, leaving the users with no effective cultural broker. Without too much trouble, one of the heaviest users of the program generator acquired the cultural broker role. The job moved out of IT entirely, but management hadn't known it was there in the first place, so it didn't cause a ripple at the upper levels.

Some of the marketing users, however, thought that they were probably not employing the full power of the package, because without technical support from IT, they shied away from some of the more "technical" features. In one specific example, someone tried to use a formatting feature but didn't succeed. When the cultural broker couldn't figure out what was wrong, the user decided to use a less convenient format.

The situation in this electronics firm suggested that I might be able to find places where some potentially useful software wasn't being used because no cultural broker was available or forthcoming. It's a bit difficult, though, to attribute causes to events that didn't happen, so I had to make some inferences. For instance, I noticed that the larger the group of potential users of a system, the more likely one of the users was to become a cultural broker.

In the case of Ninth National Bank, only three potential users had actually seen a need to try the system. None of the three evidently had sufficient motivation or technical bent to get it going, and it withered away on a shelf.

In a situation like that, the IT department could have increased the chances of success by supplying a cultural broker, at least during the early stages. Or they might have tried to create a larger user community.

Even though a small group of users is less likely to create its own cultural broker, there will always be some individuals who have just the right combination of skill and motivation to succeed with a new system without assistance. Some of these individuals become missionaries for the new system, recruiting other users with such enthusiasm you begin to suspect they're receiving a finder's fee for each convert. Actually, their biggest payoff seems to be acquiring the role of cultural broker, with concomitant respect and attention from their colleagues.

And the future for programmers and analysts? Commercial applications are supposed to "eliminate the need for programmers." But the simple truth is that they're not that well designed or well implemented and won't be for a long time. And, the more important information systems become to their users, the more critical the programmer's role becomes.

No, I think both programmers and analysts will still be around for a long time. But their roles will change. One such role is that of systems programmer. Installing and maintaining individually programmed systems is straining the supply of competent systems programmers. As a result, some applications programmers are moving in an even more technical direction.

Another changing role is system designer. If systems are to become truly user-friendly, we're going to need ten times as much work on their designs before they even reach their users.

But the greatest new demand is for programmers and analysts to move in the other direction—not so much further from the technical side as closer to the users' side.

The culture brokers I have encountered have retained or acquired the basic technical skills of programming, but also have more than the typical programmer's share of "people skills." These culture brokers, whatever they are called, are first of all good listeners.

Secondly, they tend to be generalists—interested in more than one thing and capable of learning new things quickly. And this includes a strong interest in people—they like people and enjoy helping them.

Good culture brokers are good problem solvers they get the job done, regardless of what it takes. If software is going to continue to succeed, we'll need a lot more such people. It would pay us to start finding them and training them straight away.

For more on "people-skills," see my People Skills Bundle at https://leanpub.com/b/peopleskillssoftbutdifficult .