As a problem solver or a programmer, to be able to solve a problem or fix an error effectively, it's more important to have, among other skills,

• open perspective and keen instinct on the possible causes of a problem, and
• the skill and ability to deduce the root cause by method of  elimination.

I believe in a decision support system as opposed to a decision making system. It's a common design and education issue when designing, implementing and deploying such support systems as WTF database.

A user should be educated (which is hard) to expect to use the system to help him make a decision, not to make a decision for him--an all too common real life fallacy. A study reported on the news "Spell-Check Can Make Writing Worse" in March is a classic example. Apparently, many people let the word processor completely make grammatical and writing decision for them.

Technical support service is a common example where people (both the user and the tech support) fail to have an open perspective on the possible causes of a problem.

Once, an office worker working on payroll found himself unable to access the VMS mainframe payroll system via his terminal emulator on his PC. He called tech support who walked him through on checking various things on his PC and on the mainframe--to no avail as everything seemed working. Then he was referred to the hardware vendor who asked him to check on this and that on the hardware--again to no avail as again everything seemed working.

That went on the whole day.

So I helped. First, I tried to see if it was hardware or software problem. It's not software because I took my laptop to test on various locations in the office. The terminal emulator could access the payroll system at some location but not a few the others. As for the hardware, it seemed to be the problem of a few jacks through which the PCs were connected to mainframe.

So I traced the jacks and their cables to look for physical damages. It led all the way back to the computer room where all the hubs, telephone switches and the mainframe located. Found nothing. 

Then I noticed a few lights on a hub were off. I traced the power cable to eventually a power extension cord buried under a pile of wires, which was accidentally switched off! That was the problem! A power cord was turned off by accident (probably by the cleaning crew).

In retrospect, silly, huh? Why didn't the tech supports locate the problem, given they're sitting in front of a WTF database system as well? It's because they only sought for the causes directly generated by their products--a narrow perspective.

A best thing a support system can do is to help make the user smarter, not dumber and lazier.

During the 80s "quality" craze in the business world, many executives believed control charts, statistical and quality control software helped them improve productivity but failed to realize that it's the knowledge of the users behind those tools that helps improve productivity.

In tech world, the technology-first mentality (as opposed to knowledge, education and leadership first) manifests itself as situations where a management jumps from technology to technology (such as FastCGI to ASP to JSP to CORBA, etc.) believing it will somehow magically make their software smarter, better, faster and easier to use.

There's also a real implementation issue--the search strategy, so to speak.

Perlmonks is a best piece of WTF database system powered by real human being. Still, very so often the respondents have to ask a poster to clarify his question before they could give him a sensible answer--something very hard or next to impossible to be done by a machine.

Another issue is common case versus special case fine-tuning, which is very doable but just needs continuous attention from the designer and creator of the system. What did I mean by that? Let's consider a few examples.

A candidate selection system that picks a potential successful candidate based on his/her academic achievements could do consistently pretty well on average on "common" cases but fail completely on "special" cases (such as Albert Einstein or Evariste Galois). But a competent interviewer could pick out a special case easily.

Same situation with financial trading system, it does well on "normal" situation but not on special situation, such as market crashes.

Fine-tuning between common and special cases in every algorithm is a tradeoff problem. Either you make the algorithm favors and includes the common cases more often at the expense of the special cases or vice versa--but not both--just as you can't convict and acquit someone at the same time. 

That might be also partly why the tech supports failed to locate the problem in the power cable incident above. Their WTF database probably wouldn't have shown a power cable as a likely cause even had such an information been in the system. 

Many knowledge system implemented a rating system where users rate the on answers they receive, presumably, to help the system to better the correlation between questions and answers. Again, the fine-tuning of such correlation automatically by the system requires careful intervention by the system designer or maintainer. A setting leading to too frequent an adjustment on the correlation can result in the system returning the answers seemingly in a random manner. An overadjustment issue, so to speak.

All in all, any system that helps a user to solve problems is only as good as the problem solving skill of the user himself. But of course, a good database is always welcome and helpful.

Google helps most of the time, but the problems that have you staring at the screen for hours, giving up, sleeping for eight hours, then staring at the screen again - those are the ones this is meant to address. Once I knew what the problems were, I knew enough to be able to google for them. But if you've only got a vague "feel" for the problem, google is useless unless it's a very common problem.

What I'd like is a simple bulleted list. The most common solutions would be at the top, whereas the rare and unusual would be down at the bottom. That way you can work your way through "Did you chmod 755?", "Is the first line '#!/usr/bin/perl'?" all the way down to "Are you using version x.xxxx of perl on a Redhat 6.2 system with packages x,y,z installed?"

once the solution is found, where does it go?

How about "into a patch for the documentation or the error message"? Would that solve the problem, not the symptom?

Would that solve the problem, not the symptom?

In most cases, yes. But it's of little use to anyone who has to use the old packages. ISPs aren't well-known for having the absolute latest version of everything, and improved documentation can't help if you can't tell where an error is coming from.

The database isn't meant to be the final solution to the debugging question. By all means, when a solution is found, send in the patches for the benefit of future generations. But I think that this can serve a useful purpose for those looking for a quick solution to what might be a simple problem.

The first was an error in the DBD::mysql package that was reporting an error for the wrong statement

You are referring to the error in Unexplained MySQL Error, where you showed some horrible code, didn't want to listen to the advice given to you, and then said that there was an error in the DBI.

If you want to claim a bug in an established module, you must produce a piece of code where the error is repeatbale, but we haven't seen any such evidence.

Instead, you are sweeping your bad coding habits under the carpet and then claiming that it must be somebody else's fault.

A WTF database won't help you. You must learn from your errors. Blaming a module won't make you a better programmer.

Laziness, impatience, and hubris are good for you. But excess of pride will make you go down in flames.

That's the one - not my proudest moment :). Yep - I put up no code in the beginning, asked "why is this statement not working", and expected the PM to help me. Give me a break, I was frustrated all to hell and had had absolutely no progress for a few hours. And bear in mind I didn't claim that the error was in someone else' code until I was absolutely sure it was.

I didn't follow up (post code where the error is repeatable) because A) Someone had already reported the problem, and B) I had already solved my problem thanks to another poster's solution.

Would the WTF database have helped me find this? I don't know - the only search terms I had available were "perl" and "database", which I'd expect would produce quite a long list of suggestions. But I'd hope that one of the first things I'd see is "try using trace()", which was the suggestion that ultimately led me to finding the bug.


_{PS. If the code is, in fact, as horrible as you say it is, I'd like to know what I can do to improve it (and by association, my whole programming style). Feel free to do it in a private message to avoid crowding this node (unless you want to maintain your Anonymous status, which is fair enough}

The time is only lost if you don't learn anything from it. One thing to learn is that there are fewer "simple, harmless" operations than you might want to believe.

Seriously, one of the big "problems" with DBI is that it abstracts away a lot of messy behavior in the underlying database APIs. That problem is also a major feature, but it tempts people into thinking that they don't have to understand what's going on under the covers. That's a recipe for trouble.

If you're going to be doing any serious database work through DBI, you must understand the underlying vendor API. It also helps to have a firm grip on how DBI is abstracting that API. Without this, you risk getting surprised by things like errors that you think should be caught at prepare() time not being caught until execute() (because the underlying database doesn't support prepared queries, but DBI is simulating them for the sake of generality).

Thinking of this as a reactive "where do I go for help once I've realized I'm off in the weeds" problem is tempting. The trick is to do the up-front work so that you know where the weeds are before you find yourself in them.