Zen and the Art of Systems Analysis

Meditations on Computer Systems Development

by Patrick McDermott

2. THE TAO OF DESIGN

Information is a verb, not a noun.—Michael Dertouzos

A Design must have the Right Aspirations. Chapter 2 discusses design issues, such as of User Interfaces and data records, covering some things you should keep in mind when designing a system. We’re called Systems Analysts and analysis involves breaking things down into their component parts to understand the system. But we probably should be called Systems Synthesists, since the goal of all our effort is to synthesize the pieces back together into a better system than we started with. And synergistic synthesis is what Systems Design is all about.

In this chapter we’ll try to learn some techniques of design, what you would learn in my design dojo if I opened one. A d?j? is a place where a way is taught. The word Tao, pronounced halfway between “Dah-Oh” and “Dow”, means path or way, and came into Japanese as dō. The “-do” on the end of the martial arts Jūdō, Kendō, and Aikidō are the very same dō, and it also appears at the end of Bushidō, the way of the warrior. The jō simply means place, so a martial arts sensei (teacher) will teach at a dojo. The Japanese seem to be able to elevate anything to a way, there even being Sadō, the way of Tea, as delightfully explained in Kakuzo Okakura’s 1906 The Book of Tea. A way can be a way of life. To some Americans, computers can be a Way. Many followers of the Open Source movement treat hacking (in the original, good sense of the term) as a way. Eric S. Raymond, in The Cathedral & The Bazaar, recommends that you Study Zen, and/or take up martial arts, if you want to truly understand hacking. “The mental discipline seems similar in important ways.”

A Protest From One of the Inmates

In his book The Professor and the Madman, Simon Winchester describes an incident concerning a W.C. Minor, M.D., a doctor at the Broadmoor Criminal Lunatic Asylum in England. Dr. Minor had contributed significantly to the Oxford English Dictionary by providing numerous citations of word usages. Imagine the OED editor’s surprise when he visited the good doctor and discovered that although Dr. Minor was at the asylum and was indeed a doctor, he was not at the asylum as a doctor, but as an inmate. He had been adjudged criminally insane after committing a grisly murder.

To avoid any such confusion, let me be clear up front: I am one of the inmates Alan Cooper refers to in The Inmates are Running the Asylum. Subtitled Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Cooper finds the root of the problem to be that programmers are designing user interfaces, which he feels they have no business doing. I’ll grant you some of the UI’s I’ve seen drive me crazy, but are we programmers all that bad compared to other fields? How about automobiles? Computers have not been around as long cars, but one night after teaching a class at UCLA I drove to LAX down The 405, “the busiest freeway in the world”, with no lights on. I could not for the life of me figure out how to turn on the lights in the rented Mitsubishi Gallant. It had three or four posts protruding from the steering column, and switches everywhere. I tried twisting, pulling, pushing and clicking, all to no avail. I had a tight connection to make and so did not have the time or patience to keep playing with it.

[   [   [

“Computers are just too hard to use.” So how about a little tech support? If you buy a new $100,000 Jaguar and come upon a tight parking space, what number do you call to get advice on how to park? Answer: there is none. Once a product becomes mature, the manufacturers cease giving advice on routine operation. And computers are now mature.

And we programmers are faulted for known bugs that go unfixed. I drive a classic Datsun 280Z, a sports car that received numerous design awards. The User Manual explains the use of the hatchback and warns: “Be careful not to bump your head on the latch when the hatchback is open.” In the 30+ years I’ve owned the car, I’ve bumped my head approximately 1.35 million times. Since they put the warning in the manual, they obviously knew the protruding latch was a problem, but they get design awards for their car; if it were software, the designer would be denounced.

And of course the lack of standardization drives us crazy. The same actions are done completely differently in each application, even in different versions of the same product. But what about in other fields? Very few things in life are standard. Tell me, where is the shoe department in the Nordstrom in San Francisco? Where is City Hall in Hoboken? Where is the men’s room in the mall in St. Louis? And what I most want to know: where is the damned headlight switch in a Mitsubishi Gallant?

Outline or Refactor?

Stephen J. Gould, the late Harvard paleontologist who wrote many successful books on various topics, was asked in an interview how he prepared his manuscripts. The interviewer was surprised when Gould said he wrote them out in longhand. “Wouldn’t it be better to use some word processing software? It’s so much easier to move paragraphs around.” Dr. Gould feigned confusion. “Why”, he asked, “would anyone want to move paragraphs around?” He went on to explain that he devotes much time to working and re-working his outline, and that before he writes his first sentence he pretty much knows where every paragraph belongs and what it will say.

In Life on the Screen, on the other hand, Sherry Turkle describes her quandary with a course she took in college that required her to write a composition every three weeks, with an outline due at the end of the first week. She discovered she could only fulfill this requirement by writing the entire composition in one week, then extracting an outline, and holding the completed paper until the due date two weeks later. She describes her method as “bricolage”, allowing the organization to emerge as she tinkered with ideas.

[   [   [

I could never be as exact as Gould in my outlining, nor as undirected as Turkle, but certainly some organizational thought should precede writing a book. If you have written a book, perhaps you’re like me, constantly re-organizing and moving sentences, paragraphs, sections and entire chapters. To be honest, sometimes the chapter location for a topic is pretty arbitrary, even after a lot of thought. Sometimes it’s just stuck somewhere. Writing a computer program works the same way. Ideally, we do a top down design, but if we’re doing something new, the program might just evolve. Turkle also rebelled at a programming class she took in which the instructor insisted on top-down structured programming, which did not match Turkle’s mental processes. My homeboy (he’s from Oakland) Jack London said there were nine steps to a book. They were: Write, write, write; Revise, revise, revise; Write, write, write. Martin Fowler has written a book called Refactoring: Improving the Design of Existing Code. The book is needed because programs often evolve into poorly organized collections of statements, and the book gives techniques for sorting them back into order. For some programs the advice is similar to London’s: Code, code, code; Refactor, refactor, refactor; Code, code, code. But, no cheating, you must do the refactoring!

The organization might not matter as much as you think. Only once in my career did I give a presentation to the CEO of a Fortune 500 company. My boss’ boss’ boss’ boss. My two teammates and I were in the conference room about five minutes before the presentation was scheduled to start when one of us casually thumbed through the handouts of the presentation to discover the pages had some how been shuffled into the wrong order. In fact, the order was about as random as you could get. We only had five minutes, no staple puller or stapler, and about 25 copies that were wrong. So we made a command decision: we simply sorted our overheads to match the order of the handouts and gave the presentation in random order. To make a long story short, no one noticed! The presentation went just fine, we received many compliments on it, and all we asked for was approved.

Excerpts from a Status Report

Annie the Analyst

These status reports illustrate how your goals change as the project proceeds. At first, you should be open to anything, the sky’s the limit, and more is better. They want a printer that not only prints, but brews espresso and makes Krispy Kreme ® doughnuts? Write it down, it might be possible. But as you hone in on the task, the meaning of “goodness” changes: you now consider less, not more, progress. At some stage you must rule out the impossible. This is another of those middle way situations: to close ideas off too early is as bad as to fail to concentrate your effort later on. Project scope is shaped like a funnel, not an hourglass. Hourglasses are good for egg timers and figures, but not project scope.

Presentation Tips

One of the most important skills you’ll need to get ahead after you become a systems analyst is the ability to make a presentation. You need to be able to stand before a group of people and demo your creation, teach them how to use it, and yes, even sell them on the idea of developing it in the first place. I saw an article recommending every Army Officer’s personal library should contain, along with the obvious choices of Clausewitz, Sun Tzu and Keegan, a book on PowerPoint. In the new army, “We never retreat, we just re-boot!” What’s true for these warriors is true of code warriors: presentation skills are an important asset to your career.

My students asked me to put together a few tips on the topic, and so you find here some more or less random observations.

[   [   [

Ben Franklin is supposed to have said: if you want me to speak all day, just give me five minutes to prepare. But if you want me to speak for five minutes, I’ll need all day to prepare. Or the comment “Sorry to write such a long letter; I didn’t have time to write a short one”. Plan what you are going to say. If they ask you to talk for one hour, they probably don’t mean a half hour, but they don’t mean an hour and a half, either. Proper preparation will also help prevent nervousness.

Here’s a piece of advice you probably won’t like. If you’re giving a presentation, you must get there one full hour before you’re scheduled to speak. In fact, pretend like you are scheduled an hour earlier. Why? First, one of the secrets to a good presentation, both for your audience and your own piece of mind, is not to be nervous. If you head out early, a flat tire or traffic jam won’t throw you into panic mode. If you don’t know where the place is, don’t worry; you can afford to get lost. It also makes it possible to recover from preparation problems. If the door’s locked, the projector missing or the room arranged wrong, you can usually find someone and get it corrected, which you won’t be able to do if you don’t have that hour to spare. If everything’s fine, you can have a cup of coffee, read a newspaper, or just explore. You’ll be glad you did.

There are some things that should never be said in a presentation. First and foremost, never, ever say: “I know you can’t read this”! How many times have you been at a presentation where an illegible slide is put up and the presenter says exactly that? Look, if you know they can’t read it, fix it so they can. But if for some ridiculous reason you don’t fix it, at least act surprised: “My goodness, you probably can’t read that!” It’s bad enough you were too disrespectful to make a readable presentation without insulting them by making it clear you intentionally allowed it to be unreadable.

And don’t admit nothin’! If you make a presentation error, simply correct it. Don’t accentuate the negative. Never say: “I forgot to tell you about this”, just tell them. Never say: “I already told you this, but …”; if it bears repeating, repeat it; if not, don’t. An especially never say: “I’m really nervous.” There’s a very good chance they won’t notice if you don’t tell them, and every time you say it, you force yourself to notice it, and make it worse.

Designs that Should be Flushed

Award time. What’s the dumbest design in the history of the World? Not just systems, but any design. Think for a minute, then see if you agree with my answers. First, the runners up: The third Dumbest Design In History is the Caps Lock on the PC. They know it is a problem because Microsoft Word ® even has a feature to reverse the error it causes. Remove the key, or make it smaller, and put it in a less prominent place. It’s not as bad as a system I saw where the help key was F2, right next to system disconnect key F1, but it’s so annoying to so many people to easily beat that one out.

[   [   [

Now, the first runner up: The second Dumbest Design In History is: the low-flow toilet. There aren’t many plumbers in Congress as far as I know, but that didn’t stop Congress from designing a toilet and making it illegal to make any other. Congress passed a Law requiring low-flow toilets with no idea if they were even possible. They erred in not passing the predecessor law changing the outmoded law of physics that requires two, or sometimes three flushes to do the job in these toilets, which uses far more water than a single flush from the “water wasting” design.

[   [   [

So what’s the dumbest design error in history? No, not the clock on the VCR that always flashes 12:00. This design wins the Dumbest-Ever Award because it’s been repeated over and over and over and over again. A man can get to the moon faster than a woman can get into a restroom. Why aren’t there ever enough women’s restrooms? Has no architect ever gone to a play, a ball game, a concert, and seen, or stood in, the women’s room line at public facilities? The feminist responds it’s a reflection of the lack of woman designers, but despite feminine inroads into this formerly male-dominated profession, brand new buildings designed by women still have the problem! And surely even the male architects have gone to a play with a wife, mother, or friend of the opposite sex and had to wait on her?

Bad UI

Our weakness as an industry in designing interfaces can be seen in the titles of two leading books on interface design. Alan Cooper’s The Inmates are Running the Asylum implies the present design teams belong in an asylum, and Jef Raskin’s The Humane Interface implies our designs are so bad as to be inhumane!

My girlfriend worked for a law firm where one of the three partners decided to form his own office. Although he was liked and respected, many of the staff were reluctant to join him at the new office. “I’m not willing to do all that work”, they said, “to set up the new equipment. Not just the computers, printers and the network, but even fax machines and telephones need to be programmed. The various machines are all different. You have to install all that software. Forget it!” And you thought computers were going to simplify our lives.

Consider flashing, blinking and beeping to catch the user’s attention. Flashing and blinking are examples of features, like cutesy sounds, that are initially seen as cool. After a little while, they seem cute. Not much later they are annoying. Eventually they’ll turn your users into axe murderers looking for the idiot that programmed the sound and light into the system. So use them with care. Forget the Netscape HTML blink tag, and while you’re at it forget Microsoft’s marquee. The one time it would always be appropriate to use any of these would be if you really hate the users of your system and want to punish them, or want them to leave your website and never come back.

But seriously, if you are considering attention grabbers, some ideas to consider: Use them sparingly, not for normal, routine conditions, but only for important information. In a nuclear power plant, don’t use flashing red to indicate that the coffee is ready and the same flashing red to indicate there’s a core meltdown that will kill every man, woman and child within 500 miles of the plant. Do you routinely call the police when you hear a car alarm? Of course not—it’s 99.99% certain it’s a false alarm. In other words, it should be based on level of importance and used consistently. Consistency is important both within your system and across other systems in use. And special indicators should turn off when the problem is fixed.

Overuse of any of “fail-safe” mechanisms causes the fail-safe to fail. I observed the failure of a technique due to overuse on a system. The users of the system had prepared little cards with codes:

Every command ended with “Y”. When I asked, no one knew why all the Y’s. As I was playing with the system, I typed D without the Y. A little screen appeared asking

Are you sure you want to Delete this record? Y-Yes N-No

So the “Y” was actually answering a confirmation message meant to prevent errors. But since the users had to confirm even the most trivial command, they thought of the Y as part of the command and so never even saw the confirmation.

Pickpocket’s Paradise

When I was installing an Accounts Payable System in Korea, one of the startup tasks was to fund the petty cash account. As you probably know, a petty cash account is intended to allow ready access to small amounts of cash to cover minor everyday expenditures for which a check would be inappropriate or inconvenient. The AP Manager, Mr. Park (anonymous enough, since 95% of all Koreans are named Park, Kim or Lee) wanted to put several million US Dollars in the fund. “Mr. Park, $1,000,000 ain’t petty!” we told him. But he did have a problem and one we hadn’t anticipated. Korea has a cash economy. Being an American company, we had the odd habit of paying our employees by check, but being in Korea, the company itself brought cash in on payday and cashed all the employees’ checks right then and there. If you are a pickpocket, I have just one word of advice for you: “Korea”—They don’t use plastic there; everyone is carrying lots of cash. So when the company had to pay a port fee or hire stevedores, they used cash for the payment, which could be substantial, so they needed to make large cash payments.

In Japan the perception is the opposite: checks are quaint. Why would you send me a piece of paper that I have to take to my bank that they send to your bank which sends the money to my bank so I can get the money? Why not just have your bank give my bank the money? When I lived in Tokyo, I paid my rent by telling my bank to deposit the correct sum in my landlord’s account. So in Japan you give a list of payments to your bank instead of mailing a check to each payee. Unfortunately, I had joined the team after the design was completed, and our analysts had missed some of these differences because of cultural blinders. It never occurred to them that payments could be handled any way other than the way they were handled in the USA at that time, despite the fact that the US had once been a cash economy like Korea, and is moving toward an electronic system more like Japan.

Don’t Over-Automate

You’ve probably seen something similar to the following, maybe even done something like it yourself: A document has been typed into a computer. Someone needs a copy of the document, so he gets a copy on a floppy, but it’s in incompatible software, so he can’t load it onto his computer. He and the author call tech support, and the three of them spend an hour and get the document successfully loaded on the computer. A happy ending? No! Even a two-finger typist (real programmers don’t touch type) can type a two-page document in ten minutes. In the scenario above, three hours were spent to avoid ten minutes of work!

One time I worked on a team that had just acquired a new modeling tool and needed to convert from the old tool to the new one. While the data administrator and the lead programmer held a long, boring meeting to discuss how to use exports and APIs to convert the old model to the new, I went to my cubicle and manually entered the new model into the new tool, finishing before the now unnecessary meeting had figured out how to accomplish automatically the task I accomplished while they talked about it. Since I was new to the project, I also benefited by learning about the model in the process.

Or how about this conversation: “Isn’t Barb coming to the meeting? George, you were going to tell her about the meeting.” George replies, defensively: “I couldn’t, Email’s been down all day.” Incredulously: “Uh, George, she sits at the desk next to yours! Don’t you ever talk to her?” If Email is down, you can send a postcard, a memo, or leave a note on the person’s desk. It wasn’t that long ago that there was no Email or even voicemail, but now that we have them we can’t live without them.

We technologists often see a benefit in technology for technology’s own sake. When we reach the end of our analysis and design effort, we should have designed a significantly better system. If the new system doesn’t change your way of doing business, don’t bother. So hopefully you won’t be paving the cow paths or putting disk brakes and rack-and pinion steering on the horse buggy. You should never simply automate current bad system so you can make the same mistakes more efficiently. it should change your way of doing business.

What You Can’t Give

The sci-fi classic A Hitchhiker’s Guide to the Galaxy ends with a computer revealing the answer to the ultimate question. Alas, you will only have the data you’ve a place to store, and so although the computer had computed the answer to the ultimate question, the computer did not store the question, so no one knew what the question was.

An analyst had designed a key report in a system I was working on that would be a statement summarizing the customer’s activity and computing a new balance. Unfortunately, there was no place to keep the previous balance, so the calculation was not possible. Often, after a system has been designed, users will a want calculation based on uncaptured data. So think it through, make sure you have it.

p.s. No, “Nêmô dat qua nˆn habet” isn’t Japanese, it’s Latin. Got to get some mileage out of the two years of Latin I had to take in High School (—in Japan!).

Type, Status, and Date

Type, status and date are probably the most dangerous words you’ll encounter in systems design. Whenever you hear these words, you should immediately ask what type or status. For example, you’ll surely find universal agreement that your customer database will need to track “customer type”, and you’ll surely reserve space for it. After you’ve set the database up, however, you’ll discover one person’s type is “small, medium or large”, another meant “individual, corporate or government”, still another meant “minority-owned, women-owned, or neither”, etc., etc. The problem with type is usually there are several different types from several perspectives and you might miss one.

A similar problem exists with status. But with status, there is not usually a status missed, but several that are incorrectly combined. For example, the order status might be thought to proceed through a life cycle: open, filled, paid, closed. That’s the usual sequence, but what if your customer pays in advance? In this case, you can either close it, in which case it will never be filled, or leave it open, in which case the payment is not acknowledged. In fact there need to be two independent fields: fulfillment status (taken, filled, back-ordered, or canceled) and payment status (open, paid, or overdue).

I have also encountered the missing qualifier with an invoice date. Shortly after a new multi-million dollar system was installed, the users asked us to do an analysis of how timely payments were on invoices and embarrassingly enough we were unable to do so, because despite the fact we tracked six dates on the invoice—the invoice date, the date received, the date entered, the date paid, etc.—we did not track the due date of the invoice. The analysts on the project just assumed that one of the six dates had to be the one, but sure enough, we didn’t have this basic data.

Type, status, and date always need at least two qualifiers. The first will be the name of the entity, such as invoice, payment or order. But it’s a mistake to stop there. There will also be another qualifier to explain what about that entity is being tracked.

Payment Level

Here’s a quick quiz. In most businesses there is a customer who makes an order for several items. The order is usually represented by an Invoice entity, because the receivables department usually collects the payments and they deal with the invoice. Either way, the customer got some package of goods and now needs to pay for them. So the quiz: Should the payment be recorded at the Customer, the Invoice, or the Item level? Think about it carefully for a few minutes. Ready? And the answer is (drum roll): It depends! (You knew that). Any of these levels might be correct depending on how your business operates.

First the customer level. Payments at the customer level are typical of credit cards. A credit card carries a pool of debt associated with you, the customer, not with any purchase you made. Payments and charges are accumulated into the pool, called the balance, and no association is even attempted between the payments and the charges. So if, for example, you buy a book for $20 at bn.com, and CD for $20 at Borders, then make a $20 payment, American Express makes no attempt to decide whether you paid Barnes & Noble or Borders, or paid half of each. What if you went to Hawaii three years ago, and at the end of the trip your card showed a $1,000 balance? If the balance has remained $1,000 despite much activity on the card, you might argue that the trip to Hawaii has never been paid off. On the other hand, if you took a trip to the Caribbean last year, you could argue you had paid Hawaii off, and that the balance was actually attributable to the Caribbean trip you took last year, since you chose to Calypso instead of paying the debt off. I’ve read articles where it was claimed the US is still paying for World War II. The argument goes that during the War, the National Debt increased by billions of dollars and has never gone down. Therefore that portion of the debt should be attributed to WWII. But it’s just as easy to argue that WWII was paid off long ago, and that at various times the US built a national highway system, fought wars in Korea and Viet Nam, and went to the moon, instead of paying the debt down. An accountant would say you’re arguing LIFO versus FIFO. In LIFO, “Last In, First Out”, each payment would be assumed to pay the most recent debt, and so WWII is still on the books. In FIFO, “First In, First Out”, WWII was paid off long ago and our most recent ventures are responsible for the debt. In any event, if you track at the customer level there is no matching of payments to invoices and if that’s how your company operates the correct answer to the payment level is “Customer”.

Businesses that don’t have a revolving credit plan might track at the invoice level. Each order is expected to be paid for, and an invoice is either mailed or included in the package with the goods. The customer usually pays the invoice in full. If he makes a partial payment the invoice remains open until the payments match the invoice total. If the customer returns an item for credit it will work similarly to another payment and will close the invoice when the credits and debits are equal.

But it is also possible the payment should be applied at the item level, and if your business needs at the item and you have it at the invoice level it can be a real problem. I will never forget this problem because of a very embarrassing experience caused by this kind of design error. American President Lines had spent some millions developing a new receivables system that was supposed to cover the entire company and all its subsidiaries. APL owns ships for ocean freight, but also owns a rail subsidiary, originally to move the cargo from ports to inland destinations, but now carrying even domestic traffic. The subsidiary was called API, American President Intermodal—“intermodal” being the shipping industry’s term for combined ocean and land transportation.

I had not joined the project until after the design was finalized, but I was now the manager and publicly responsible for the project during roll out. Right away, API developed a problem. At first we thought it was political, in that since API had had its own system, and resented big brother APL imposing anything on them, they were being overly critical, especially since the system had already been installed at many other sites without any problem. But after closer examination it turned out there was a design incompatibility. APL needed payments applied against invoices but API needed them applied against items. This was because of the chaotic nature of the rail system. You might find it hard to believe, but freight forwarders who want to ship cargo in the rail system don’t reserve a boxcar, they just find an empty car and put cargo in it. The owner of the rail car then has to figure out who used the car; in many cases they guess wrong the first time and bill the wrong company. Sometimes they bill the forwarder when the actual shipper should pay, and sometimes they bill before the information has filtered through as to who actually used the car. Therefore the customer will frequently “decline” some of the items on the invoice. Since these items need to be researched to find the correct customer, it is essential that the system track payments at the item, not the invoice, level. The analysts who visited API failed to realize that the two companies operated so differently, and now we had a fully implemented database that could not meet API’s most basic need. After wracking our brains long and hard we were forced to come to the politically embarrassing decision to admit we could not serve API and support their request for funding for their own system. Several hundred hours of programmer effort had been devoted to API programs and requests were scrapped. Ouch! Even though I had nothing to do with the design, I cringe to this day when I think of it.

Redundant & Superfluous

Here’s an old story. John McCoy, a hatter, decided to make a new sign for his shop. And so he designed a sign with his name: “John McCoy”, his profession: “Hatter”, his motto: “Fine Hats Made and Sold”, and a big picture of a hat.

Before going to the expense of having the sign made, he checked with several friends to get their input. He wanted to be thrifty, and the cost of the sign would depend on how much was written on it. The first friend suggested he remove the word Hatter: “Since it has a picture of a hat, and says ‘Fine Hats Made and Sold’, it’s obvious you’re a hatter.” He asked a second friend who advised him to remove his name from the sign. “After all, people don’t care who you are, they’re just looking for hats”. His third friend suggested removing the words ‘and Sold’ from the sign. “After all, you wouldn’t have a sign up if you weren’t selling hats.” He spoke to another friend who suggested removing ‘made’ from the sign. “After all, the customer doesn’t care where the hats are made, just that they are good hats.” His next friend suggested removing ‘Fine’. “After all, you’d be expected to call your own work ‘fine’, so no one will believe it anyway.” So that leaves a sign that just says “Hats”, which is obvious from the picture, and so he dropped that. In the end, the sign had no wording on it at all!

I say this is an old story because although any DBA can appreciate the sentiment, the story is attributed to Benjamin Franklin. Redundancy is very expensive, not because it uses space, but because of the Law of Unsynchronized Data. If you have identical data stored in two places in your database, you can guarantee they will not agree with each other. If you copy the data, then turn the computers off, have them surrounded by an army of security guards carrying night vision scopes, you can be sure that when you turn the computers back on the data will be different. So the only way you can keep data in sync is only have one copy of it. In The Pragmatic Programmer, Andrew Hunt and David Thomas espouse the DRY principle: “Don’t Repeat Yourself”; you can say that again: Don’t Repeat Yourself. One more time, Don’t Repeat Yourself. At the risk of repeating myself: Don’t Repeat Yourself.

There should be a place for every thing, and everything in its place. Don’t carry redundant information without extraordinary justification.

Gates at the Gate

The story goes that Bill Gates died and was outside the Pearly Gates, speaking with Saint Peter. St. Peter said, “You know, Bill, you’re pretty marginal. When we look back at your life there is some good and some bad. What I’m going to do is let you decide where you’ll go.”

So St. Peter takes him around Heaven. There are all these people sitting around on clouds playing harps. It looks pretty boring to Bill. They go down to Hell. There are all these people chained to desks, there are terminals in front of them, and they are furiously fixing Windows ® bugs. It’s a little warm, of course, but not all that bad. Bill thinks, “This reminds me of the happiest time in my life, when I was in New Mexico founding Microsoft. It’s not much hotter than that, and I love programming of any kind.”

So Bill says, “Saint Pete, I want Hell.” He’s duly processed and sent to Hell. Except when he gets there, it’s not quite what he expected. It isn’t just warm, it’s in flames, people are being burnt everywhere. And the terminals on the desks are all smashed so all you can do is sit there bored looking at them, you can’t program.

Bill says, “Hey, something’s wrong here, I need to see St. Peter.” So he’s sent to see St. Peter, and complains: “This is nothing like what you showed me.” St. Peter says, “But Bill, of course you saw the Demo Version …”

Chapter 3. Politics, Gurus & Consultants

Copyright ©2003, 2008 Patrick McDermott