A matter of time
-
A longtime customer of mine recently switched receiving/inventory software and was having trouble reconciling between a specific report from the new system against values that my software imports. For some reason we have imported almost $300K more that their report shows for last month. Of course the assumption is that my import is wrong. The customer is unhappy, my colleague who has been trying to figure this out for a couple of days now is unhappy and they decide that I should get involved which makes me unhappy. :sigh: Narrowing the focus, it became clear that the records their report is missing all fall on the ending day of the month. Looking closer, those missing records actually all have a datetime of 2018-09-30 23:59:59:000. Further, the time part of the datetime field for all records is either all 0s or maxed. :confused: Getting back to the source system and the report in question, I set the ending date to 2018-10-01 and viola, there are the missing records, however they are showing a date of 9/30 in the report. Interesting...now run the report for just 10/1 and they are gone. OK, got it...somebody forgot to make the ending date inclusive! :wtf: I explain this all to the customer...my numbers are right, yours are wrong and here's why, along with 'you need to show this to the other software vendor'. Instead, they asked if I would send an email with the explanation that they could share with management and the other vendor. (so wtf did I just spend 15 minutes explaining it! :mad:) Sensing that I was about to say something sarcastic, my colleague agreed to do it...of course I had to explain it all over again and basically dictate the message anyway. :sigh: That's almost 2 hours spent chasing problems in someone else's software. Can I please just work on my own stuff now? :)
"Go forth into the source" - Neal Morse
Things like this are why I advocate for BA's with technical skills. Explaining why a system did what it did shouldn't require a developer. In the absence of someone else who could explain, I feel like you did the right thing. The absolute worst thing any vendor (or department if internal) could tell a user is that it's someone else's fault/issue without an adequate explanation. Pointing fingers without backing it up is one of the quickest ways to loose a client's trust.
-
I have found that this process of explaining to non-technical people was is actually occurring is what occupies a vast portion of my time, and I don't have a problem with that. I have embraced it, and am rather good at it at this point. One point to consider is that coders are considered "dime a dozen," but someone who understands, and can explain, why something behaves the way it does is a valued asset to management. In terms of your import being "wrong," I might contend you could improve your import by excluding the time. If it is always 0 or max value, why is it even stored? Why is the field not a "date" instead of a "datetime"? If you don't have control over the database, how about always clearing the time on import since it obviously serves no purpose. It would then accurately represent a date only albeit wasting five extra bytes, and potentially causing problems such as this, each time to do it. As a developer, your job is not solely to satisfy the immediate requirement, importing the data in this case. It is to anticipate problems that MAY occur such as this reporting problem, and solve for those, as well. So, technically, I would consider those "2 hours spent chasing problems" AS working on your own stuff.
Thanks Greg, I think you have misunderstood the issue. My import pulls monthly data from another vendor's system. The customer uses a report from the source system to check what was imported and finds that the import has quite a bit more than the report. The assumption at that point is that my import is wrong. Using the query viewer from my import, I can modify the query by removing the convert functions for the datetime to date, and reveal that the records not being pulled in their report (for the same date range) have a time element and all occur on the ending date. Using the other vendor's software, I can pull the same report extending the ending date by one day, and now those rogue records show up along with records for the 1st which I don't want. Again, this is the other vendor's report...nothing I can do about it...either a query problem or a UI problem. This is clearly the other vendor's issue. I really wanted to stay out of it, which is why I demonstrated multiple time to the customer how this is a problem that must be addressed with the other vendor...just show them this report run under the two date ranges and they will surely see the problem. Yes, that was two hours spent finding a problem with another software vendor's report. :)
"Go forth into the source" - Neal Morse