gregoryyoung has had an interesting month; after being evacuated from New Orleans to Baton Rouge, and then to Ft. Lauderdale, he finds himself in Atlanta, still trying to figure out what he's going to do with himself. In the meantime, he's writing.

For the last newsletter I wrote a brief article describing what design patterns were and the educational benefits that they can have as they are generalized knowledge. I hope at least a few of the managers out there read the article and realized that it may be a good idea to pursue this further with their staffs. This week I will be writing about another kind of pattern which is directed at managerial staff.

Before I go into the realm of the business anti-patterns I should first explain the concept of an "Anti-Pattern". An anti-pattern is a well-documented and commonly-made mistake for which there are known solutions. They are extremely useful in identifying common problems within your knowledge base; since they are common problems they also tend to include many possible paths to fix the problem in the long term along with the risks of each path. This being said, let's jump right into a few that you can immediately identify in areas around you, but hopefully not at your own company!

"Founderitis"

A very common problem in a company occurs when the founder(s) of the company stays on board as its CEO for too long of a period of time. It is rather obvious that it takes a very different type of person to grow a company from one store to five hundred than to grow the same company from five hundred to five thousand. This anti-pattern is extremely well known and is fondly known as "Founderitis". This pattern can also be identified with the founder(s) of a company's inability to delegate tasks to subordinates leading to micromanagement. As you can see, this is a pattern that applies both to business processes as well as software design our next pattern will apply to both as well.

"The Golden Hammer"

A great piece of wisdom came from Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." This sums up this anti-pattern very well; it is very hard to identify solutions to process problems when you have never learned that there are better ways of handling the problems. This anti-pattern is also often seen in not having a true understanding of WHY something worked and therefore trying to apply the same working solution to problems it was never intended to solve. There is but one solution to this anti-pattern: knowledge.

"The Underpants Gnomes' Business Plan"

I believe I am the first to ever officially title this anti-pattern; it can be a direct cause for "Hockey Stick Revenue Projections".

[In the gnomes' cave]
Gnome 1: This is where all our work is done.
Kyle: So what are you gonna do with all these underpants you steal?
Gnome 1: Collecting underpants is just phase one. Phase one: collect underpants.
Kyle: So what's phase two?
[Silence]
Gnome 1: Hey, what's phase two?!
Gnome 2: Phase one: we collect underpants.
Gnome 1: Ya, ya, ya. But what about phase two?
[Silence]
Gnome 2: Well, phase three is profit. Get it?
Stan: I don't get it.
Gnome 2: (Goes over to a chart on the wall) You see, Phase one: collect underpants, phase two- [Silence]
Gnome 2: Phase three: profit.
Cartman: Oh I get it.
Stan: No you don't.
Kyle: Do you guys know anything about corporations?
Gnome 2: You bet we do.
Gnome 1: Us gnomes are geniuses at corporations.

Is anyone wondering what Phase Two is? Unfortunately this ridiculous jump in logic is quite common with business plans (as well as software design cycles). A classic example of this pattern can be seen in WebMd. WebMd provides, in its own words, "connectivity and a full suite of services to the healthcare industry that improve administrative efficiencies and clinical effectiveness enabling high-quality patient care." (A must read: this article from The Motley Fool, in which they admit that even the Motley Fool is a product of Underpants Gnomes thinking.) Where in this statement do they say how they make money? With the exception of a few non-profits the entire purpose of a company is to make money.

The problematic logic here is that the site needs to reach a critical mass before phase three. This can be directly correlated to the "Hockey Stick Revenue Projections" anti-pattern as it describes a sudden and continued jump in revenues for no apparent reason. Perhaps this is why the company continues to post losses.

It is important to realize that these patterns exist in both software design and in business management. Although the tendency is to have software designers and business professionals who can't stand to be in the same room together, we fight many related battles and we can actually learn a lot from each other. I will be expanding on this thought in the next newsletter.

Greg Young - gregoryyoung@experts-exchange.com

"Time to go to work, work all night
search for underpants hey!
We won't stop until we have underpants
Yum tum yummy tum day!"

Books:
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, William j. Brown
I'M Not Anti-Business, I'M Anti-Idiot Dilbert, Scott Adams (identifies many anti-patterns in a humorous way)
The Six Sigma Handbook, Thomas Pyzdek

Web:
Wikipedia
"Hockey Stick Projections"
The Motley Fool
"The basic laws of human stupidity"
The Burning Bag of Dung and other Environmental Anti-Patterns

I went to college at a school that featured three-story dorms, and on each floor, there was a lounge with a telephone that was limited in that you could call a campus telephone number or make a local call. You could call home as long as your parents were willing to accept a collect call. I won't swear that it didn't have a dial on it -- it was a LONG time ago.

Standard practice was to answer the phone with the number of the dorm. One typically lazy college afternoon, a buddy of mine was in Dorm Three -- not unusual because the four dorms were arranged in a quad, and each held about fifty students -- when he heard a telephone ring, so, kind soul that he is, he answered it. Unfortunately, he lived in Dorm One at the time, and that was what he said.

The person on the other end of the line asked for the person she was trying to contact, apparently oblivious to the salutation that had erroneously informed her that she had called Dorm One. So my buddy decided to spend about four weeks -- he was looking for something to write for an anthro class -- answering as many telephone calls as he could, in as many dorms as he could. He would alternate, first answering the phone and correctly identifying its location, and then answering the phone with a reasonable, yet incorrect answer. He wouldn't say something like "DeSoto and Sons Mortuary" because that wouldn't have been an on-campus number, but he did use "Financial Aid", "Dorm Seven", and "Physics Board".

He charted the results, and came to the conclusion that the very device that had made it possible to communicate with people around the world (except from a dorm lounge) had also made communication -- defined as two people speaking and listening to each other -- difficult, if not impossible, because people didn't listen.

So what? Well, there was a column last week from the heart of the technological world -- the San Jose Mercury -- that says the more devices we use to transmit and receive information, the less we interact with the people around us.

The columnist decries the trend -- her son downloading a game while waiting for a waiter in a restaurant, her husband checking today's baseball score -- as being rude. There's no real argument that it is; few things annoy me more than to play golf with someone who spends half the time on a cell phone. "It's almost as if, in this media-saturated culture, we're afraid to be alone with our thoughts," Dawn C. Chmielewski wrote. "For even a moment."

We're not just afraid to be alone with our own thoughts; we don't want to have to have anything to do with anyone else, either. Oh, we'll answer their emails (maybe), but heaven help us if we actually have to talk to someone. For that matter, the corporate world is reinforcing the feeling that we shouldn't be talking to them. Dial almost any company with more than about half a dozen employees, and you'll get voice mail. Dial a company with more than 200, and you might get their call center, located somewhere where they don't speak a language you can easily understand.

But it's not that we just don't want to talk to each other. As long as we don't have to personally interact, we're much happier -- we're more free. No one can tell us what to do if we're across town receiving a text message; no one can see us not doing it. They can't hear the tremor in my voice saying "I was caught in traffic" if I punch a few keys on the keyboard.

What's particularly tragic, though, is that we're isolating ourselves in a fabricated world in which we're the only player. We can know everything -- but we don't want to know anyone. We're taking the "Me First" attitude to a whole new level, and while that gives us a false sense of freedom from encumbrances, it will most certainly destroy the texture of our lives.

I can see the obit now: "Joe dyd. Funrl @ 10 Mon. Clk here."

Atabia may be a newbie by Experts Exchange's standards, but it's pretty obvious that he's been around a few blocks somewhere; less than a week after joining, he posted this question in the New To EE topic area. We've edited it slightly for length (not a lot -- it was pretty well written).

First, before anyone cries plagiarism, let me say that this document borrows heavily from Eric S. Raymond's "How to Ask Questions The Smart Way" originally hosted here. However in the interest of consolidating it down to a more concise representation, update it a bit, and give it a flavor more appropriate for Experts Exchange, I thought I'd rework it and post it for both users and experts to refer to when it is warranted.

The key to getting your questions answered in any type of Internet forum, newsgroup, or mailing list is to phrase your question in such a way that will make those you're asking WANT to answer your question. Even on Experts Exchange, the experts themselves receive almost nothing for answering your question, beyond the satisfaction of helping someone else out, and the mental challenge of a new or sticky problem. However, if you, the asker, have not taken the time to try to answer the question yourself, or to think through the problem, we as experts see red flags of a lengthy and time-consuming answer, and will often as not skip your question in favor of someone else who has exhibited those qualities.

The key: Do your homework to make it EASY for us to help you.

1) Think through your problem. If you haven't even tried to answer your own question, we'll be able to see it right away. This is one of the first questions to get skipped, because it's guaranteed to be be the tip of a large follow-up-question iceberg.

2) Search First. If I can find the answer in 5 minutes using nothing but Google, you haven't done your homework, and are a waste of my time. Before you even ask a question, make sure you search Google, and check out at least the first page and a half of entries. Search the FAQ for the site or newsgroup you're asking in. Read any documentation relating to the products you're using. And when you have done all these things, mention it in your post.

3) Try to remove all your assumptions before asking. "How do I get Windows to run Linux?" is a bad question, because chances are pretty good you don't want to use Windows to run Linux. Apparently, what you want is to run Linux. Tell us what you are trying to accomplish, and what limitations you have. Don't assume you're on the right track.

4) Ask in the right forum and only one forum. Don't ask a question about Javascript in an ASP.NET forum or a Windows question in a C++ forum. If you haven't at least narrowed down the specific area or technology in which the problem occurs, it's pretty much a sure thing you haven't done Item 1. If you're unsure which of two forums to post in, post it in one, use a pointer question in the other.

5) Reduce your code to the simplist possible configuration that still presents the problem. If you're working on a project, create a second test project that reproduces the same problem, but doesn't have all the extraneous code that doesn't relate. This helps two ways. One - just doing this often helps the problem area to present itself, and your question will be answered before you ask it; and Two - We do not want to read through 200 lines of irrelevant code to find the 3 lines of code that are actually the problem. The only exception to this rule is a stack dump or similar logging-type information, which should be hosted elsewhere with a hyperlink to get to it if needed.

6) Specify the problem exactly. Start with a short description, followed by exact steps to recreate the problem, what the expected result was, and what the actual result or error was. Be sure to include exactly what software or languages you're using, and what version, along with platform or OS. If the problem is intermittent, specify what causes the problem to come and go (as well as you can), or mention that you can't figure out what causes the discrepancy.

7) Briefly (!) describe what solutions you've already tried. This lets us know you've put some effort into it, and also gives greater clues as to what the problem might be.

8) Read your own post - carefully! Make sure your post is spelling- and grammatically-correct. Leave your l33t-speak for your teen-age friends on IM. Make sure you've said exactly what you needed to say, and remove anything that doesn't relate to the question at hand.

9) Write a message subject that reflects your question or at least the topic. Subjects of HELP!!!! or URGENT!!!! are useless. Likewise subjects of "I'll never get this right..." or "What is causing this problem?" are better left for friendly emails. Better subject lines are "Windows crashes every time I run calc.exe" or "Emails are being sent to wrong addresses." Your subject line is your first chance to engage our interest. Don't waste it.

10) Describe the raw symptoms, not your conclusions. You're asking for help, so obviously you don't know what the problem is. List symptoms in the order they occured. The only exception is listing possible conclusions that you have tried and eliminated. This will help the answerer by avoiding trying things you've already tried. Although, you should be very careful here. Just because you tried something, doesn't mean you tried it correctly.

11) Ask a question, don't make a statement. You'd think this is obvious, but apparently not. Wrong: "I can't get this code to work." Right: "My code is throwing error 33, but I don't have any files involved. What else could cause error 33 would show up?"

12) Think about what answer you want to receive. Don't ask a yes-or-no question unless you want a yes-or-no answer. Don't assume the answerer will want to expound, or be able to read your mind as to which area you want them to expound into. Wrong: "Is it possible to create a mortgage calculator in Coldfusion?" (Answer:yes) Right: "What's a good algorithm for calculating variable-rate mortgages?"

13) Assume you're the one doing something wrong, and take a humble, courteous attitude. Even if you secretly think the error is someone else's, it's better to be proven right, and get an apology from the person in the wrong, than to be arrogant and rude, and have to be the one to apologize if you're wrong.

14) Avoid the "Can I...?" question. For example, "Can I pass in a boolean to the DeleteTree() function?" Try it. Did it work? Then the answer is "yes." If not, the answer is "no."

15) Avoid large-scale "How do I..." questions. "How do I?" questions are very often violations of Item 1 to begin with. But large scale ones are impossible to answer. This medium is not appropriate for long discourse. If we can't answer your question in a paragraph or two, we won't answer it. Wrong: "How do I make an e-commerce site?" Right: "What are the advantages of Motley's Paradigm over RFT-format (or vice-versa) when creating an e-commerce site in PHP?"

After you've asked your initial question:

16) If you don't understand a response, or have a follow-up question, use the same techniques you did in asking your question - search for the answer first, read the manuals for clues, etc. Don't assume that because someone already took the time to answer your question, they are now personally devoted to seeing you succeed. Also make sure a follow-up question is a follow-up question, and not an entirely new question, which should be posted seperately.

17) Say Thank you. Chances are you'll have another question sometime in the future. If you "Pay" the answerer with additional satisfaction from knowing they helped someone, they'll be more likely remember your name and be eager to answer you in the future.

18) If you find the answer to your own question, post the results so future readers can find it.

We all remember the scene in War Games where Matthew Broderick changes a grade for a blonde Ally Sheedy, just before he finds a back door to the Defense Department's A-Number One Perfect Computer.

The gag became less of one in a town just down the road from me, when Alexander Ochoa, all-league football player now attending Occidental College on a needs-based academic scholarship, was accused of changing his grades (along with those of several other students) last May. The school district suspended him, and held a hearing to decide whether he should be expelled -- which would have put his college career in jeopardy.

Ohcoa fought the charges, and on June 24, he was cleared of the charges by the school board and awarded his diploma. During the same period of time, another student at the same school was charged with similar offenses, but it wasn't Ochoa.

Fast forward to the end of September. Last week, Ochoa was again charged, this time the legal system, with multiple counts of hacking into the high school's computer systems. He's due to be arraigned October 7.

Speaking of fun and games, if you're into blogging and want to reach all of those billions of people in China, the Reporters Without Borders group has published a Handbook on Blogging. The group also publishes a Censorship World Championship.