Indeterminite and stateless

Those were the watchwords of my day at work today. One of the projects on which I am working involves integrating two systems that don’t talk to each other. One system is an off-the-shelf meeting room reservation system; the other product is a tasking application–a helpdesk trouble ticket system. Integration went pretty well, until a few weeks ago when I found it difficult to update the tasking system when a meeting room changed in the meeting system. The reason for this is that only viable method for doing this is through an “indeterminate” or “stateless” mechanism.

Today, I more or less caved in and went with a simpler solution. It’s a little more painful for people who will be servicing the tasks creating by the system, and it is certainly a tactical solution, but it will work.

And yet, I feel defeated. There should be a way of making this work the way I want it to work, but I can’t get enough information about how the meeting application works to figure out what that way is. I’ve read through thousands of lines of their code–it is literally scattered about my office–but I just can’t figure it out. As a completist, I feel frustrated. As someone who is working toward building a system that all people who use it will be happy with, I feel like I’ve let some people down. But given budget constraints and time limits, there’s not much more I can do at this point.

I’m going to try finishing up “The Graveyard Shift” tonight. But I need to relax, wind down a bit first.