THE BROTHER-IN-LAW SYNDROME

by Wayne M. Krakau - Chicago Computer Guide, June 1992 - Newsware, August/September 1995

It's becoming an epidemic. I've found yet another victim of the dreaded Brother-In-Law Syndrome. In this condition, someone with little or no background in an appropriate field, most frequently a brother-in-law, and almost invariably a male, provides computer advice.

I'm sure the government is commissioning a study as to whether this heavily skewed gender proportion is a genetic or a sociological phenomenon. Could it be the gene that causes men to freely dispense directions when they aren't familiar with the area? Or, maybe it's the same gene that makes guys with inadequate automotive aptitude freely disperse advice about a disabled car. (Oops, I've done that!)

I first discovered a variation of this syndrome while working on mainframes. Corporate officers would be approached by manufacturers' sales people. By giving a dazzling technical presentation to a non-technical audience, the sales people could avoid serious questions about the validity of their facts. They could freely use what's known as the FUD (fear, uncertainty, and doubt) factor to threaten catastrophic results upon the purchase of competitive products. The corporate officer would then override the results of expensive internal feasibility studies to purchase the product in question. The technical staff would be stuck supporting this product even though it wasn't the appropriate solution.

In the micro arena, the advice often originates, not with a sales pitch, but with a request for advice from someone who "knows" computers. The outcome of ignoring advice from family members (especially the aforementioned brother-in-law) is obvious. The advice is especially compelling since, in most cases, the advisor has no financial interest in the purchase (excluding, of course, those who bill themselves as "consultants"). Considering the lack of journalistic quality control in the microcomputer industry, the advisor can often quote magazine articles praising the suggested product.

The problem lies in accepting advice from a single source without appropriate justification, and, in not properly evaluating the source of the advice. For example, if I advise a client to purchase a product, and the client accepts my recommendation without explanation, I get scared. While it does wonders for my ego, it raises the possibility that the client is deferring to my (hopefully) greater knowledge and experience to such a degree that he or she is actually suppressing questions or filtering out possibly important details about his or her needs. This is the one last chance to catch any discrepancies between my mental picture of the clients requirements and what they really are. My justification of the product choice is a critical part of the analysis and specification process. Advice from a brother-in-law (or his surrogate) removes this critical step.

As to the source of the advice, most alleged consultants in the computer field are actually free-lance programmers. While programming is a perfectly honorable and creative field, having superior programming skills says nothing about your ability in business, product evaluation, hardware, and even software design. And, most of the "brothers-in-law" aren't even in the consulting business. Some are programmers in mainframes and minicomputers. Others are just microcomputer enthusiasts or hobbyists. Some merely use computers in their work.

The most recent occurrence of the Brother-In-Law Syndrome was with a company that purchased a network that included both new and existing machines. A member of the Board of Directors knew someone (maybe a real Brother-in-law?) who bought a particular brand of computer to tinker with at home. Based on that glowing accolade, the board member convinced the other directors to override the analysis of the company's in-house computer department and to purchase a dozen of these computers. It was justified by stating that it was better to split the order so that the company wouldn't become too dependent on one vendor.

After watching the computer staff suffer with configuring these machines (we had preconfigured one example out of the computers that we sold them so that they could simply duplicate that configuration on the rest of our systems) I finally gave them some free advice (no money had been budgeted, they had bought a considerable amount from my company, and I'm kind of a soft touch). They eventually replaced all of the video cards and got the systems to work, but they never really fully optimized the configuration and they worked a lot of unpaid overtime (salaries only). Another victim of the "Brother-In-Law Syndrome".

For smaller firms without the corporate overhead and lacking a professional computer staff, the dangers are greater. One client of a colleague canceled the purchase of an incredibly sophisticated integrated accounting system when the brother-in-law (a real one) of the owner offered to write a custom application for very little money. His qualifications: he was a microcomputer user at work who dabbled in programming on the side. The result: the company's growth was severely hampered due to the time and money lost in attempting to fix the custom system. They eventually bought packaged software, anyway.

A related disorder illustrated by this example is that of "Programmers Disease". This is an overwhelming desire to solve any computing need by custom programming. The term used in the industry is "reinventing the wheel". A more efficient and effective line of attack would be to investigate possible software solutions in the following order of preference:

1. Single package.

2. Single package with application specific add-on packages.

3. Multiple packages linked with commercial packages.

4. Multiple packages linked with custom programs.

5. Modifiable single package with externally added custom modifications.

6. Modifiable single packages with internally added custom modifications.

7. Complete custom software.

While there may be some dispute about the exact order of this list, I believe that the trend of going to custom software only as a last resort is logical. However, if all you have is a hammer (programming expertise), everything begins to look like a nail (custom programming). Remember that the full custom programming method is the most expensive (potentially hundreds of times more then packages), most risky (you become the test site), and most lucrative (for the programmer).

While we do custom solutions, they are only a last resort after examining other alternatives.

The main advice that I can give to protect you from these maladies is to always get justification for a proposed solution. A qualified individual will not be offended and will, in fact, take reasonable questions as a sign that you are interested in being an active participant in the analysis and design of your computer system. That participation is the key to a successful project.

As always, questions, comments, and topic suggestions are always welcome.