Tag: skepticism

Why House is the most educational show on TV

No comments

If you didn’t catch last night’s episode of House, “Top Secret”, you should. It proves why House is the most educational show on TV. In an era when shows like Medium and Supernatural and Psychic Detectives are big hits, what a relief to have a show that sticks to pure rationality and reason for solutions to problems.

Last night’s show was interesting because House had a dream about a marine, who he’d never seen before, and who suddenly turned up as his patient the next day. And yet House stuck to his guns, did not leap toward supernatural explanations, and in addition to figuring out what was wrong with his patient, he also figured out how he could have had a dream about a patient before he met the patient. And it was all through reason.

I’m skeptical about some of the medicine on House. Granted, I don’t know enough about medicine to be sure, but I suspect like in any TV show, things are dumbed down, glazed over, and literary license is used. Setting that aside, the main focus of the show is not on the medical mysteries but on the methods used to solve them. Deduction, induction, reasoning, ruling out, ruling in, these are the way problems get solved, not by a crystal ball, lines in the palm of your hand, or Tarot cards.

Last night’s episode reminded me of one of my favorite Isaac Asimov Black Widower mysteries, “The Obvious Factor”. A mystery is presented at the gathering whereby it seems totally and completely impossible that there is any rational explanation. The guest tells a story and has his hosts completely perplexed. But not Henry the waiter. Henry points out that there is one obvious factor that has been overlooked by everyone else: that the guest is lying. And that, in fact, was the case. The guest made up the impossible events, and after ruling everything else out, the only rational explanation left was that he was lying. How many people would have liked to believe that the events described in the story could only be explained by supernatural forces, when an obvious factor still remained?

Gregory House may be an arrogant ass and have the bedside manner of foley catheter. But he’s one of my heroes because he doesn’t give into flim flam and nonsense. He keeps looking for rational explanations even when everyone else has given up.

The cost of not being skeptical

No comments

One of the projects on which I am working is a conference room reservation system of inordinate (and unncessary) complexity. This project involves the integration of three different software packages: (1) An off-the-shelf conference room scheduling package; (2) Microsoft Exchange; and (3) an off-the-shelf tasking package. None of these packages have native interfaces to any of the others and integrating them has been a challenge. (My specific role, aside from being an advisor) has been to integrate package (1) with package (3), something that I have done successfully and one of the few successes ofthe project thus far.

The off-the-shelf conference room scheduling package is developed by a small company, but they have been fairly responsive in acceeding to customizations we have requested. We ask for a customization, they give us a time estimate and a cost, and we then pay them to make the customization. But the product itself, in my opinion, is not very well written. I have read through much fo the code because I needed to integrate it with the tasking product so I have a good sense of this. Early on, I discovered, for instance, that when you book a conference room, the software sets a default meeting time of 2 hours. This is just too long. Most meetings don’t last 2 hours (they just seem like they do). If people aren’t paying attention, they will end up booking a conference room for twice as long as it’s needed and that prevents other people from using an already scarce resource.

I pointed this out months ago, and also pointed out that in a better written application, the default length of a meeting would be a system setting. But in this application it is not. It is hardwired into the product. I pointed out that if I had some time, I could find the problem and fix it, but I didn’t have the time to do it. Instead, we contacted the manufacturer and asked them to make this change. They were happy to do it for us. They told us it would take 1 month, and it would cost $1,700 to evaluate the change (figure out what they needed to do) and another $1,700 to “fix” it the way we wanted it. This was a few months ago. We didn’t expect them to get started right away. The “1 month” would begin once there was an opening on their calendar.

Yesterday, frustrated that this hadn’t been fixed, and by the fact that it seemed to me we were being over-charged, I decided to tackle this problem on my own. Their code is somewhat of a mess, if you ask me. So instead of working on what I was supposed to be working on, I set aside an hour to solve this problem. It ended up taking me 57 minutes. It was like untying a knot, but with some trial and error, I eventually found the code that set the default meeting time. Sure enough, it was hardcoded in at 120 minutes (2 hours). I changed this to 30 minutes, which is what The Powers That Be wanted it set to. I tested it and it worked great!

Here is where my skepticism paid off. For budgeting purposes, my team “bills” our time at $500/day. There are 8 hours in a day or 480 minutes. It took me 57 minutes to solve this problem, and doing the math, you could say that to solve this problem it cost $59.38 of my time. Compare that to the 1 month and $3,400 estimate that the guys who actually made the software quoted us. Essentially what this means is that their cost quote was 57 times what it actually cost me to fix the problem. And their time quote, in terms of business hours, was 168 times the time it took me to fix the problem.

The irony is that no one really questioned this when they gave us the quote. They merely said “okay” and issued the check. Once the check was issued, there is nothing we can do to get the money back. We emailed the company yesterday telling them that we fixed the problem, what we did and how long it took. We argued that in the interested of maintaining a “trusted partnership” they should return the money. But of course, they are under no legal obligation to do so. So who is really at fault here?

I’d argue that the vendor genuinely thought it would take a month to solve the problem. They simply don’t know their own code well enough to give a better estimate. I’d argue further that we should have been more skeptical about the quote to begin with. We should have asked for more detail about why it cost so much or why it would take so long. But we didn’t. So perhaps we got what we deserved in this case. I’d love to think that we would learn from this experience and not repeat a mistake like this in the future, but you know me: I’m skeptical.