≡ Menu

Excerpt from “Boiling the IT Frog”

Excerpt from Chapter 1

CHAPTER 1: POOF, THERE IT IS!

Magic in IT isn’t a Good Thing

One of my favorite quotations is from Arthur C. Clarke, “Any sufficiently advanced technology is indistinguishable from magic.” The quotation is important because I believe that most misunderstanding about technology comes from the line that we cross when a technology becomes so magical that it can no longer be understood by normal people.

Magic has a mystical language, full of strange utterances and spells, and IT has the same sort of language, full of mysterious phrases like n-tier architecture, real-time response, cooperative processing, and two-phased commit; strange words like firewall, parallelism, and functionality; and acronyms like ERP, CRM, CICS, DMZ, RAID, SOAP and SQL. Is it any wonder that business people get confused? They begin to think they should hire an interpreter just to understand what their own people are saying.

Secret 1: Technology that crosses the line into magic leads to unreasonable trust, illogical thinking, and inappropriate wizardry.

With magic we expect the impossible, and so it is with technology as well. Most of us don’t understand how the technology works when we’re able to talk into a cell phone and engage someone on the other side of the world in conversation, but we take it for granted that it will work. And because the ease of a transcontinental phone call seems so impossible, it’s not a big leap to expect something more technically challenging without understanding why the challenge is so great.

When something is magic, we don’t expect it to follow logic, and we don’t apply our common sense. That can be a bad thing when it interferes with our ability to run a business.

Unreasonable Trust
Let’s take a few examples of magic from my own experience. Back in the 1970’s, I developed the Material Requirements Planning (MRP) system used in manufacturing plants by Digital Equipment Corporation (DEC). The DEC MRP system took the schedule of computers to be built and used a computerized “Bill of Materials” (like a recipe that tells you how to build each computer) to calculate the demand for each part needed to manufacture those computers. The MRP process is complex, but it’s relatively straightforward and understandable. The math is done the same way you would figure things out manually, multiplying the demand for a specific computer by the number of components needed in the computer, and subtracting the inventory that’s already on hand to create a report that tells the manufacturing people how many of each part to order.

But at DEC it got more complex because people wanted to apply the latest theories from inventory control. Some college professors had determined that there are various formulas for determining the optimum quantity of a part to order. Some formulas are simple, like always ordering in hundreds. Other formulas are extremely complex, taking into account the weighted average of past orders in conjunction with the weighted average of forecasts of upcoming demand.

Our MRP system at DEC allowed the production managers of each manufacturing plant to choose the way that the order quantity is calculated for each item. When we looked at the result of using various order quantity calculations in different plants, we saw something interesting. When the more complicated calculations were used, it was more likely that an error in the order quantity would go unnoticed. So an erroneous MRP order for more than a year’s supply might go through unchecked because the people doing the ordering would figure that the confusing calculation was just the computer doing the best thing for the company.

To say this another way, when the function of software is understood by its users, then the users are likely to “sanity check” the result and catch any error. But once the software has gotten so complicated that the process is no longer understood by the users, then the software has crossed the line into magic, and the users develop an unreasonable trust in the system. At this point the users of a system lose their accountability. If something goes wrong, then the error is blamed on the computer, because no one understands how the computer has calculated the result.

Illogical thinking
A few years ago someone gave me a DVD for Christmas, but it was in the wrong format; I like the wide-screen version, and this was narrow screen. I took it back to Best Buy to exchange it, and I encountered a problem. Although most people would regard the two different versions of the same DVD as an even exchange, the Best Buy computer had been set up to treat the two versions as two entirely different stock numbers. And because my gift DVD had been purchased on sale at a price below the current price, the Best Buy clerk insisted that he could credit me with the sale price, but that since it wasn’t an exchange for the same item, he would have to charge me for the difference between the credit and the current price of the “different” DVD.

After several appeals to various levels of management, I finally got my DVD without an additional charge, but this is another example of magic. In this case the “magic” of the system is dictating the policies of the store, even though the computer system is leading those policies to an illogical conclusion. Of course it’s a system design error; there ought to be a way to treat two different item numbers as equivalent for exchange purposes. But more important is the fact that the clerk insisted on following the system, even when it made no sense. The clerk was unwilling to even consider that the computer could be wrong. Magic led to illogical thinking.

The Attraction of Wizardry
Back in the 1990’s I was flying on Delta Air Lines, and I had to change a ticket at the airport reservation desk. It was a relatively simple change from one flight to another. But my ticket was discounted, and a different fare basis had to be taken into account to determine an additional charge.

At that time Delta had an older system in which the reservation agent had to type commands into the computer and then wait to see the result. So as I stood patiently at the counter, the agent typed command after command, occasionally pausing when the computer had an unreasonably long delay. About five minutes later, I mentioned to the agent during one of the delays, “I’ll bet you’re looking forward to when Delta replaces this system with something easier to use, aren’t you?” The answer astonished me, “No, actually I’ve spent a lot of time getting good at this system; people look up to me, and I would hate to see a change.”

The reservation agent had fallen into the wizardry trap. She was now a wizard, and so she was unreasonably committed to keeping the system the way it was, even though it offered low productivity to the rest of the employees, particularly the non-wizards.

[get the book to read more of Chapter 1]

Copyright © 2007 by Harwell Thrasher

Buy book for Amazon Kindle
Learn more

The $9.99 Kindle edition of the book can also be read on iPad, iPhone, Blackberry, Android, PC and Mac — An Actual Kindle is Not Necessary. Click here for more details.

Or buy a new Kindle for as low as $139

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this. For more information on the use of cookies on this web site, see http://blog.makingitclear.com/cookies/

Close