The Write Stuff 2016 Bundle

Curated by Kristine Kathryn Rusch

Hundreds of writing books get published every year, and most of those books are written by people who have written…a book on writing. I kid you not. These people have a method or a scheme or they teach a writing class—even though I have no idea how they get those gigs. (Okay, I do. They get an MFA, which universities seem to think is more important than actual writing experience.)
Those writing books have nothing in common with the writing books in this bundle. Together, the authors of the books in The Write Stuff 2016 Bundle have more than two-hundred years of writing experience, and have contributed more than five hundred award-winning and bestselling books (fiction and nonfiction) to the world of literature.
We know writing, the writing life, and what makes a writing career. And we want to share it all with you.
Even though the books in this bundle discuss craft, including one of the classic writing books of all time, most of the books you'll find here explore the career killers, things like how to put butt in chair on a regular basis, how to organize your business career, and the all-important (at least to me) how to make a living as a writer.
So if you are a writer, or are simply dreaming of becoming a writer, this bundle is for you. – Kristine Kathryn Rusch
The initial titles in the Write Stuff 2016 Bundle (minimum $5 to purchase) are:

• Weinberg on Writing - The Fieldstone Method by Gerald M. Weinberg
• How to Negotiate Anything - Freelancer's Survivor Guide by Kristine Kathryn Rusch
• Stages of a Fiction Writer by Dean Wesley Smith
• Business For Breakfast Vol 2.: The Beginning Professional Publisher by Leah Cutter
• The Rational Writer: Nuts and Bolts by Mindy Klasky

If you pay more than the bonus price of just $15, you get all five of the regular titles, plus five more:

• Creating an Online Presence for Writers by Cat Rambo
• How to Make a Living With Your Writing by Joanna Penn
• Heinlein's Rules - Five Simple Business Rules For Writing by Dean Wesley Smith
• Writing the Novel from Plot to Print to Pixel by Lawrence Block
• The Writer's Business Plan: A Plain English Guidebook by Tonya D. Price, MBA

The bundle is available for a very limited time only, via http://www.storybundle.com. It allows easy reading on computers, smartphones, and tablets as well as Kindle and other ereaders via file transfer, email, and other methods. You get multiple DRM-free formats (.epub and .mobi) for all books!
Read more.

What is the truth about 10x programmers?

Way back when I wrote The Psychology of Computer Programming, I pointed out the wide variation in programming skills. Years later, people began labeling this phenomenon 10x programmers.

On the Quora website recently, a participant asked "What is the truth about 10x programmers?"

Most of the answers there were good, but misguided. Many of today’s critical programming tasks are simply too big and complex to be handled even by a 100x programmer (not to speak of maintaining what a 100x programmer produces but does not want to be bothered maintaining).

For many years now, we have understood that the programming job is not really a job for individuals, but for teams. (Yes, an individual can produce a fine small program, such as a game. I have done that myself, many times over 60 years in the business.) So what we really want is a 10x leader/teacher of programmers. If you can’t pass on you 10x abillities to others, you’re not what we want for those enormous programming tasks.

That’s why I now concentrate on teaching 10x programmers to be 10x programming leaders, as in my Problem Solving Leadership workshops and my books such as Becoming a Technical Leader.

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!

Why Agile Projects Sometimes Fail

The gang was enjoying a BBQ Pig Out at Rudy's. It was a magical moment until Rusty and Millie started to argue about Agile software development.

Rusty started it all by saying, "Agile is magical."

Millie banged on the table with a half-chewed pork rib. "That's ridiculous. There's nothing magical about it."

"Sure there is." Rusty pulled a Sharpie out of his pocket protector and printed "AGILE" on a paper towel (which passes for a napkin in Rudy's). "There are just a few things management has to provide—like MONEY." He sketched a capital M on the towel, making MAGILE.

"Money's not enough," said Millie.

"Of course not. Management has to eliminate environmental interference.' With one smooth stroke, he crossed out the "E."

Millie frowned and shook her head, but Rusty took no notice. "And they need to Cooperate, and not just occasionally, but All the time." He added the C and A, finally producing "MAGICAL."

"Cute," said Millie, her tone sarcastic, but she was clearing struggling not to smile. "But successful projects require more than waving a Sharpie wand and pronouncing 'AgileCadabra.'"

We all knew that Rusty was pulling our legs. Millie, of course, was right. If you want to succeed with an Agile approach, you need more than magic rituals. Not only that, you need to avoid quite a few rather common mistakes that lead to failure.

Common Mistakes in Building New Things

In my experience, these common mistakes are not unique to Agile projects, but will kill Agile projects just as easily as they kill Waterfall or any other approach:

1. Committing to a schedule or cost without having any relevant experience with this type of project.

2. Using the experience on a similar but smaller project to commit to an estimate on a larger project.

3. Extending requirements to "optimize" or beat unknown competition.

4. Failing to recognize signs of impending failure and/or act on them to extend schedules, reduce costly requirements. (like those that diminish velocity by creating more frequent failed tests).

5. Failing to recognize limits of the environment or process or recognizing them but being unwilling to change them.

6. Simply undertaking too many simultaneous tasks and perhaps failing to complete any of them.

7. Not recognizing both changes and opportunities presented by a new technology.

8. Not asking the customer, out of fear, or lack of customer surrogate contact.

9. Not asking anyone for help (fear?).

10. [I invite my readers to contribute more failure dangers to this list.]

The Underlying Failure

Beneath each of these failure reasons, and others, lies one generalized failure. I explain that failure in the remainder of this article, posted as a chapter in my book, Agile Impressions.

Understanding Testing

Last week, Joe Colantonio interviewed me for his milestone 100th Test Talk. In case you haven't heard it yet, Joe extracted a few quotes and insights from this Test Talk. I've put some of them here, followed by a fascinating supporting story from one of my listeners.

Secrets

Joe asked me something about secrets of how I managed to do so many thing, and I gave a couple of long-winded answers:

Maybe the secret is, a sort of middle level, is stop looking for secrets and just figure out one little improvement at a time. Get rid of things that are using your time that are not productive and that you don’t like to do. Part of it is you have to love what you’re doing and if you don’t love it, then it’s pretty hard to bring yourself back to it.

I guess the secret of being productive if there is a secret, is to adapt to what is as opposed to what should be. Of course another way to describe testing is that it’s finding out what actually is as opposed to what’s supposed to be. A program is supposed to work in a certain way and the tester finds out it doesn’t work in that way. When you report that then somebody does something about it. If you live your life the same way you’ll be pretty productive.

One Thing Testers Should Do

Joe asked about what testers should be doing that they may not be doing, and one of my answers was this: 

I think that you need to highlight certain things, like I need to just sit down and talk with the developers and ask them what went on, what happened, what was interesting and so on in an informal way. This gives you a lot of clues where you might be having trouble.

History of Testing

On the history of test groups, I had this to say:

We made the first separate testing group that I know of historically (I’ve never found another) for that Mercury project because we knew astronauts could die if we had errors.We took our best developers and we made them into a group. It’s job was to see that astronaut's didn’t die. They built test tools and all kinds of procedures and went through all kinds of thinking and so on. The record over half a century shows that they were able to achieve a higher level of perfection (but it wasn’t quite perfect) than had ever been achieved before or since.

Automation in Testing

Joe's sponsor, Sauce Labs, specializes in automatic testing, so we had an interesting back and forth about test automation. Among other things, I said, 

You can automate partial tasks that are involved in testing and maybe many tests and save yourself a lot of efforts and do things very reliably, and that’s great. It doesn’t do the whole job.

To which, Joe taught me the expression he uses is not "test automation" but "automation in testing." We were in violent agreement.

How to Improve as a Tester

Joe then asked me how I'd recommend someone could improve themself as a tester:

The little trick I give people is that when you find yourself saying, “Well that’s one thing I don’t need to know about,” then stop, catch yourself and go and know about that, because it’s exactly like the finger pointing that we talked about before, when the developer says, “Well that’s a module you don’t need to look at,” that’s the one you look at first. You do the same thing yourself say, “That’s a skill I don’t need, it has nothing to do with testing,” then it does and you better work on it. 

How Testing is Misunderstood

There's a lot more lumps like these in the podcast, but here's one straightforward example that supports most of the things I had to say. Albert Gareev sent me this story after listening to the podcast:

"We are not NASA,"—said a Director of Development.—"My testers just need to verify the requirements to make sure that our products have quality."

What she wanted to "fix" in the first place, was that "the testing takes too long." There were a "Dev testing" phase, and then "QA testing" phase, and then "internal business acceptance testing" phase, then "client business acceptance testing" phase—sometimes even two. If bugs were caught at any point, the updated version would go through the same whole pipeline of testing. The product was indeed doing what's intended for the customers and for the company, with a very low number of incidents that were successfully taken care of.

During my initial analysis I found out that those phases were highly compartmentalized. Certain bugs had a very long life span, before the Dev team would get to know of them. Certain problems kept re-occurring. Testing was performed as a kind of a clueless Easter eggs hunt; Dev team didn't feel a need to share what code module they updated. 

It appeared to me, that the product was in a good shape only thanks to these lengthy testing phases that made chances of "stumbling upon" the errors high enough to catch the majority of bugs.

So I brought my findings back to the Director, and made a few suggestions—around collaboration, feedback loops, and especially about training testers to model risks, and to test for them. 

But she didn't buy it. She still thought that "they're doing too much testing."

I was puzzled. Frustrated. Even slightly offended, being a tester devoted to his profession.

And then I took a project manager for a cup of coffee.

The PM shared that the Director was in her first year being in charge of software development. That previous decade she spent as a director of customer support. 

"Huh."—I said.—"All these years she saw the products that already undergone a thorough testing-and-fixing process before her team could try them."

"Exactly."—replied the PM,—"She has no idea that at first it's always messy."

More on Testing and Quality

If you want to learn more about testing and quality, take a look at some of my books, such as,

Perfect Software and Other Illusions about Testing

Errors: Bugs, Boo-Boos, and Blunders

Quality Software Bundle

The Changing Role of Software Testers

Back in the earliest days (probably before most of the readers here were born, around 1958., there was no distinction between testers and developers. They were all called programmers, and the best of them were chosen for our test group (ours, on Project Mercury, was the first test group that I know of).

Our test group was copied for a number of IBM Federal Systems projects, but over the years, people started having a different sort of test group. These groups were not made up of programmers, but were largely chosen because they would be cheaper than programmers. It was widely believed that any idiot could do testing. Many times I heard managers say they could train monkeys to sit around banging on keys.

Since that time, gradually over the years, more managers have come (ever so slowly) to realize that testing is a specialty that requires special people with special training and talent. We still have many “monkey-managers,” and for those managers, the role of testers has not changed much. But where professional testing is valued for itself, yes, the roles of tester and developer have become more similar (though not identical).

BTW, the role of monkeys hasn’t changed much, but, then, some developers play that role very well.

(see also, Perfect Software)

My Earliest Computers

My father gave me a slide rule when I was about 7 years old. I used it to compute baseball batting averages, which was what motivated me at that time in my life. I still have that slide rule. It's a small, cheap slide rule, made from bamboo with plastic (or maybe ivory) faces. He bought them in quantity to give to the young ladies who computed customer bills for Sears, when my father worked for 20+ years, improving processes. The slide rules were used to check their multiplications, preventing enormous numbers of errors that had previously been sent to customers.

The next interactions were with tables of sines, cosines, and logarithms, used for more precise calculations, mostly in math classes and personal experimenting with numbers for fun.

At age 11, still in Chicago, I read a magazine article about computers, then familiarly known as "giant brains." By this time, I had been label as s "brainy" kid, and I longed to learn more about brains. I determined that computers were what I wanted to do with my life—and they turned out to be. I didn't know anyone who had ever seen a computer, let alone used one.

I watched and waited for signs of a computer, but went all through high school without seeing one.  Well, not exactly. I had a summer night  job in a large bakery computing recipe requirements for the following day's orders. I used a Monroe adding machine.

When I entered college at 16, I told the counselors I wanted to work with computers, but none of them knew anything about computers other than they had something to do with electrical engineering and physics. They decided I should major in Physics, because I was good in math, which would be "wasted in EE." One day, I saw a notice for a "computing course" using Monroe adding machines, given by the Monroe company. I was a short course, and I already knew most the material better than the instructor. But I passed, earning a certificate that I've lost somewhere along the way. It's the only computing course I ever took, and the only "degree" in computing that I ever earned.

My next encounter with a computer was when I looked in the mirror. I got a job in the Physics department as a "computer"—that was my job title. I was shown a Friden electromechanical calculator, which I used along with pencil and paper (and eraser) to invert 10 by 10 matrices for faculty members.

I graduated with honors in Physics, Math, Philosophy, and English, then went to Berkeley to study graduate Physics. I was perhaps two months from a doctorate in Physics (exams passed, thesis experiments finished and waiting to be written up), but I read an IBM ad in Physics Today looking for problem solvers. The ad described the work I had dreamed of since age 11, so I wrote to IBM and was hired as an Applied Science Representative—on June 1, 1956.

I was given no training, but my first assignment was to teach a programming course to three other new Applied Science Representatives who were to join IBM in San Francisco two weeks later. (I had a wife and 1.66 kids by then, so I needed the two-weeks pay, so I started early.)  The first machine I encountered was an IBM 607, which was a wired program machine with 20 wired program steps (this was the expanded version) and one signed ten-digit number of data storage. In my first week, using the library of manuals, I mastered that machine plus a bunch of older punched-card machines.

I spent the next week learning to program the IBM 650, a stored program machine that kept programs and data on a magnetic drum, but had wired control panels for input and output formatting. This was all theoretical, as there was no IBM 650 anywhere in San Francisco yet. When one finally arrived shortly thereafter, it was the first stored program machine I had ever seen.

While waiting for the 650's arrival, I earned a reputation as a "whiz kid" (the term "programmer" wasn't yet in use) by making the 607 do tricks. My most impressive trick was turning on all the lights on the 607 control panel, which won me a dollar bet.

When the 650 arrived, I immediately tried out a program I had written to compute tables of sines, cosines, and logarithms. With the arrival of computers, such tables were now totally useless, but I was in nerd-heaven. I was being paid $450 a month for playing with the world's greatest toy, a job I would gladly have paid $450 a month to do—though I wisely didn't tell IBM that.

Tale of the Recent Gravity Wave Discovery GW150914

[This is a guest blog by Mark G. Gray, a physicist who understands people and many other things. Reading it put a whole lot of perpective in my life.]




Thirteen hundred million years ago in a galaxy thirteen billion trillion kilometers away, a small dark sphere looms ominously near a slightly larger dark sphere.

The small sphere is one hundred thirty kilometers in diameter.  Its surface is neither solid, nor liquid, nor gas, nor plasma.  Nor is it visible except by absence; no light passes through, nor is emitted from, nor reflected by it.  But its presence is felt throughout the universe: any unfortunate structure within a few hundred kilometers of it would be torn apart by tidal forces, with the pieces glowing X-rays as they fall into the surface and disappear from the universe.  Even the light from distant stars streaming around its edges is twisted to form a distorted halo.

The large sphere is nearly identical to the small sphere, but is one hundred seventy kilometers in diameter.

Although they pass within a few hundred kilometers of each other, the spheres do not tear each other apart.  Instead they twirl around a point approximately midway between them, moving closer and faster on each orbit, past the point where their diameters overlap, finally rotating seventy-five times per second.





















When the smaller's center collides with the larger's surface, there is no sound, no light, no X-rays, no ejection of debris, nothing to indicate a collision in the conventional sense, but instead just a wobble in the merged dark shapes and a ripple in space-time that alternately doubles and halves nearby lengths relative to widths as it passes.

The remnant of the encounter is a single dark sphere three hundred seventy kilometers in diameter, a spherical wave in space-time expanding at the speed of light, and perhaps the explosion of a nearby star triggered as the wave passes through it.

Meanwhile, only two hundred forty thousand trillion kilometers from the center of the Milky Way galaxy on its Orion arm, the planet Earth is in the middle of its Mesoproterozoic era.  The super-continent Rodinia has just formed from three pre-existing continents. Eukaryotes, cells with a well defined nucleus and organelles have emerged, but not yet evolved into multi-cellular life.  The Moon, which is still geologically active, orbits the Earth in a little over three weeks.

Two hundred thousand years ago the wave front reaches the Small Magellanic Cloud, a dwarf galaxy in the Milky Way's neighborhood.  The planet Earth is in the late Pleistocene epoch of its Cenozoic era. The seven contemporary continents are in place, the glaciers are in retreat, and modern humans have just emerged and invented agriculture. The Moon, geologically dead for over a billion years, orbits the Earth in a little under four weeks.





One hundred years ago, as the wave front passes through the stars in the Milky Way's Hydrus constellation, the human Albert Einstein uses his theory of General Relativity to show that accelerating masses can produce gravitational waves in space-time.  Karl Schwarzschild publishes the first solution to Einstein's General Relativity for a spherical mass.

Seventy-seven years ago J. Robert Oppenheimer uses S. Chandrasenkahr's work on stellar deaths to predict massive stars that have exhausted their nuclear fuel would collapse under their own weight to form a singularity.

Fifty-eight years ago David Finkelstein uses Schwarzschild's solution to show Oppenheimer's singularity would be surrounded by a spherical event horizon, a black hole, from which nothing, not even light, can escape.

Fifty-four years ago M. E. Gertsenshtein and V. I. Pustoviot describe how interfering perpendicular beams of correlated light can detect gravitational waves.

Thirty-two years ago Kip Thorne, Ronald Drever, and Rainier Weiss establish the Laser Interferometer Gravitational-wave Observatory (LIGO).

Twenty-eight years ago they secure funding for LIGO.

Twenty-two years ago LIGO construction begins.

Fourteen years ago LIGO becomes operational.  LIGO operates for eight years without seeing a gravitational wave.

Six years ago LIGO is shut down for improvements.  The gravitational wave moves among our sun's nearest neighbor stars.

On September 12, 2015 the Advanced LIGO starts its first operational run, with just enough sensitivity to detect the gravitational wave that is now about four times further from Earth than Voyager 1.

At 09:50:45 UTC on September 14, 2015 the Advanced LIGO at Livingston, Louisiana detects the gravitational wave when its four kilometer length oscillates relative to its four kilometer width by a fraction of the size of a subatomic particle.  Several thousandths of a second later and three thousand two kilometers away, the Advanced LIGO at Hanford, Washington detects the gravitational wave.  The signal, designated GW150914, cycles eight times, increasing in both intensity and frequency, until it reaches an intense chirp at its crescendo.

On February 11, 2016 the Advanced LIGO team announces their detection of a gravitational wave.  The coincidence of the signal at the two detectors implies a non-local source.  The similarity of the two signals implies the detection of a single, real event.  The time difference between the signals triangulates a direction, and the red-shift of the signal gives a distance to the source.  The spectrum of the signal matches general relativity's prediction for the inspiral and merger of binary black holes and lets them reconstruct what happened:

    A black hole twenty-nine times the mass of our sun encounters
    another black hole thirty-six times the mass of our sun.  As the
    black holes scatter around their center-of-mass by mutual
    gravitational attraction, they lose kinetic energy radiated away
    as gravitational waves.  The binary black holes, now trapped in
    orbit, centripetally accelerate around their center, radiating
    more gravitational waves, losing more energy, moving ever
    closer together and orbiting ever faster.  They finally merge,
    emitting a blast of gravitational waves, to form a single black
    hole about sixty-two times the mass of the sun, with three solar
    masses converted entirely to gravitational wave energy in a
    spherical front moving outward at the speed of light.  At its peak
    the merger produces several times more power than all the stars
    in the observable universe.

p.s. No, the GW doesn't stand for Gerald Weinberg, nor for anything as small as our Earth or even our little corner of the Universe.

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 .