Friday, April 22, 2016

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)

Monday, April 04, 2016

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.

Saturday, March 19, 2016

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.

Monday, January 18, 2016

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:


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


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

Sunday, January 03, 2016

I'm excited about this promotion because it's geared to one of my favorite audiences: middle-grade readers! I've always been passionate about books written for kids ages 9 through 12. Harry Potter, Percy Jackson, Fablehaven, Diary of a Wimpy Kid... all excellent. :-) I wrote The Key of Kilenya when my younger brother, Josh, who was 12 at the time, told me there weren't enough books for him to read. He'd ripped through everything our local library had and was hungry for more.

I dedicate this promotion to him and to all other readers who love and are searching for books written for middle graders!

The Multi-Author Middle-Grade Book Promotion starts January 4, 2016 and ends January 7, 2016.

From $5.99 to FREE
Kindle Nook  * iTunes

All Jacob wants is to make the basketball team. All the Lorkon want is to control the magical powers Jacob doesn't know he possesses.
From $2.99 to $0.99

Twelve-year-old Steven never wondered where the Loch Ness monster or Big Foot came from until he found a stone box with a dangerous secret--one people are willing to kill for!
From $2.99 to $0.99
Kindle * Nook * Kobo

More than anything, Benjamin Ravenspell wants a pet, but when he buys a mouse named Amber, he gets more than he bargained for.

From $0.99 to FREE
Kindle * Nook * Kobo * iTunes

Cassandra's ordinary life is riddled with hilarious and sometimes heart-breaking mishaps as she guides herself through the world of pre-teens on the brink of adulthood.
From $2.99 to FREE
Kindle * Nook * Kobo

Part Neanderthal, but raised as a human, Arken Freeth finds that he doesn't fit in either world as he struggles to survive.
From $3.99 to $0.99
Kindle * Nook * Kobo

An eleven-year-old girl discovers she has the power to grant any living thing its one true wish.

From $3.99 to FREE
Kindle * Nook * Kobo

When a malnourished horse shows up as a rescue at the farm where she volunteers, Jacinda, a bullied girl, takes it on as a project horse, and the mare's sweet nature inspires her to spread kindness around to make a positive difference in the world.
From $0.99 to FREE
Kindle * Nook * Kobo

Jenni Kershaw and her eighth grade science class take a field trip they will never forget. Dragons and goblins and spirits, oh my!
From $2.99 to $0.99
Kindle * Nook * Kobo * iTunes

When Colin suddenly learns he has magic, he discovers that Atlantis is real, and that his new mermaid friend, Alleya, is in trouble.
From $2.99 to $0.99
Kindle * Nook * Kobo * iTunes

Bed bugs, burglars, and a missing mother. For Doodle, itís just part of a dayís work. A laugh-out-loud mystery for dog lovers of all ages.
From $2.99 to $0.99
Kindle * Nook * Kobo

To save her brother, the banshee Seven must save Atlantis.
From $1.99 to $0.99

One girl with a nightmare to live through; one ghost with a dream to live. With so much to lose, can anything be gained?

From $3.49 to FREE

Enter a world of myth and magic as young English boy Thomas Farrell seeks to discover the identity of his late father, and why he left him a strange glass orb containing a serpent...
From $2.99 to $0.99

When eating dog kibble on a dare gives 10-year-old Tawny special powers, her life nearly goes to the dogs!
From $5.49 to $0.99
Kindle * Nook * Kobo

Twins Justin and Janine discover a mysterious egg ... can they protect the hatchling while lost in Montana's Absaroka wilderness?

$3.99 to $0.99

Daniel doesn't think there's anything worse than spending a week at Camp Bigfoot . . . until he loses his prized possession: a pencil that brings his drawings to life.

From $4.99 to $0.99
Nook * Kobo

Laughing and Learning Little Life Lessons
From $3.99 to FREE

When a blast from the past shows up and makes her BFF go nutburgers, Ginnie is torn between helping her friend and getting some very important questions answered.

From $3.99 to FREE
Kindle * Nook * Kobo

Harry Potter and The Hobbit rolled into one captivating and humorous epic fantasy series that will have kids begging for more.
From $0.99 to FREE
Kindle * Nook * Kobo

Winner of the Mom's Choice Award honoring excellence in media for children. Classic fantasy adventure - quirky, funny, sinister, and action-packed
From $3.99 to FREE
Kindle * Nook * Kobo * iTunes

To save his friends from a dystopian future Earth, Nikolas leads them to a fantastic Moon in the past. But what happens when the fantastic becomes fatal?

From $3.99 to FREE
Kindle * Nook * Kobo

Explore the magical history of Kendra Kandlestar's world in this collection of bonus tales from the Land of Een.
From $4.99 to FREE
Kindle * Nook * iTunes

DREAMS: Dorothy called it Oz, Alice called it Wonderland, but Nightmares call it HOME.
From $2.99 to $0.99
Kindle * Nook * Kobo * iTunes

What's worse than stumbling upon the dead body of the Cat Lady? Being accused of her murder. Sarah Cole and her friends take it upon themselves to catch the Cat Lady Killer.

From $2.99 to FREE
Kindle * Nook

When Turik finds a special egg his Grandfather is kidnapped and he must balance his power for good with the strength of the evil that wishes to consume him.
From $2.99 to $0.99

Felicity, an ordinary sparrow learns that she can do extraordinary things!
From $3.99 to $0.99
Kindle * Nook * Kobo

When a group of crazed ninjas take over their school, the Smartboys fight back. And it all happens on a day when Monkey has the worst case of flatulence imaginable.

From $2.99 to $0.99
Kindle * Nook * Kobo

George, the magical basset hound, is on the trail of the mysterious ghosty haunting his Packmate, Tillie.
From $2.99 to $0.99

The legend of the little red hen, as told by the acorn that smacked her in the head. NO ONE IS TOO SMALL TO CHANGE THE WORLD!
From $2.99 to FREE

Carter's life changes when an old man entrusts him with a book of magical spells, one of which grants the power to raise people from the dead.

From $0.99 to FREE

Ever wonder what it would be like to be pulled into your computer? Sarah is about to find out.
From $2.99 to FREE
Kindle Nook * Kobo * iTunes

It takes more than a school trip to change Christy's life. It takes murder.
From $2.99 to FREE
Kindle * Nook * Kobo * iTunes

When a savage pirate and a corrupt businessman join forces to steal the treasure for themselves, Christopher and his crew get caught up in pirate chases, time travel, and an underground network of spies!

From $0.99 to FREE
Kindle * Nook * Kobo * iTunes

Semi-autobiographical adventures from a 20th Century Northern California outdoorsman
From $2.99 to $0.99
Kindle * Nook * Kobo * iTunes

The future looks bleak unless eighteen-year-old Lance and his young New Camelot Earth Warriors can save the planet from catastrophic climate change.

Enjoy your new books! :-)

Sunday, October 11, 2015

One Little Change

Note: From time to time, I will be adding material to my new book, Errors: Bugs, Boo-boos, Blunders. All purchasers of the book from will receive all of the new material free of additional charge. The following chapter will be added soon, along with some feedback from my earliest readers.

Dani, my wife, is an anthropologist by profession, but now has become a world-class dog trainer. <> The combination of the two produces some interesting ideas. For instance, she told me about the way attack dogs are trained to keep them from being dangerous. As usual, the big problem with attack dogs is not the dogs, but the people.

When an untrained person hears that a dog is attack-trained, chances are about one in three that they'll turn to the dog and command, "Kill!" As a joke. Or just to see what the dog will do. To protect against this idiotic human behavior, trainers never use command words like "kill." Instead, they use innocent words, like "breathe," that would never be given in jest in a command voice.

This kind of protection is needed because a trained dog is an information processing machine, in some ways very much like a computer. A single arbitrary command could mean anything to a dog, depending how it was trained—or programmed. The arbitrariness does not matter much if it's not an attack dog. The owner may be embarrassed when Rover heels on the Stay command, but nothing much is lost. If, however, Rover is trained to go for the throat, it's an entirely different matter.

It's the same with computers. Because they are programmed, and because the many meanings in a program are arbitrary, a single mistake can turn a helpful computer into one that can attack and kill an entire enterprise. That's why I've never understood managers who take a casual approach to software maintenance. Time and again I hear managers explain that the maintenance can be done by less intelligent people operating without all the formal controls of development—because it's not very critical. And no amount of argument seems able to convince them differently—until they have a costly maintenance blunder.

Fortunately, costly maintenance blunders are rather common, so some managers are learning—but the tuition is enormous. I keep a list of the world's most expensive programming errors, and all of the top ten are maintenance blunders. Some have cost over a billion dollars each, and some have lead to deaths. Often, the blunder involved changing a single digit in a previously functioning program.

In those horrendous losses, the change was deemed "so trivial" it was instituted casually by a supervisor telling a low-level maintenance programmer to "change that digit"—with no written instructions, no test plan, nobody to review the change, and, indeed, no controls whatsoever between the one programmer and the organization's day-to-day operations. It was exactly like having an attack dog trained to respond to KILL—or even HELLO.

I've done some studies, confirmed by others, about the chances of maintenance changes being done incorrectly. Contrary to simple-minded intuition, it turns out that "tiny" changes are more likely than larger ones to be flawed. Roughly, a one-line change has about a 50/50 chance of producing an error, while a 20-line change is similarly wrong only about one-third of the time.

Developers are often shocked to see this high one-line rate, for two reasons. In the first place, development changes are simpler because they are being made to cleaner, smaller, better structured code—code that has not been changed many times before so does not have unexpected linkages. Such linkages were involved in many of my top-ten disasters.

Secondly, the consequences of an erroneous change during development are smaller because the error can be corrected without affecting real operations. Thus, developers don't take that much notice of their errors, so they tend to underestimate their frequency. In development, you simply fix errors and go on your merry way. Not so in maintenance, where you must mop up the damage the error causes. Then you spend countless hours in meetings explaining why such an error will never happen again—until the next time.

For these two reasons, developers interpret such high rates of maintenance errors as indications of the ignorance or inexperience of maintenance programmers. They're wrong. Maintenance programmers are perfectly capable of doing better work than their record with tiny changes seems to indicate. Their competence is proved by the decrease in error rates as the size of the change increases.

If tiny changes are not taken seriously, they are done carelessly and without proper controls. A higher rate of error is an inevitable consequence.

How many times have you heard a developer say, "No problem! It's just a small change. All I have to do is change one line!"?

That statement would be sensible if "small" changes were truly small—if software maintenance were actually like maintenance of an apartment building. The janitor can change one washer in a dripping sink with much risk of causing the building to collapse. It's not safe to make the same assumption for a program once it's in production.

Whoever coined the term "maintenance" for computer programs was as careless and unthinking as the person who trains an attack dog to kill on the command, KILL. With the wisdom of hindsight, I would suggest that a maintenance programmer is more like a brain surgeon than a janitor. Would maintenance be easier to manage well if it were called "software brain surgery"?

Think about it this way. Suppose you had a bad habit—like saying KILL to attack dogs. Would you go to a brain surgeon and say, "Just open up my skull, Doc, and remove that one little habit. It's just a small change! Just a little maintenance job!"