Tag: work

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.