The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Dates and (especially) times are a PITA to work with.
So are third parties.
The only thing that could make your story worse is if those reports were actually Crystal Reports
The last three bugs I "fixed" were in our CRM system (which I can't even fix because they took away my admin rights) and in a third party application (which I can't fix either).
Alright, so I didn't fix anything, but at least I figured out the problems and told someone else to fix it.
The problem is that OUR software "breaks" because THEY mess up.
And because I'm spending time finding those bugs I can't do my own work.
You have to be careful not to be known as the programmer who delivers bugs and does so at a slow pace!
As frustrating as it is, making a detailed writeup for a non-technical person to forward to another dev/etc is the lesser evil. The non technical person trying to regurgitate what they were told and getting critical details wrong is even worse.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
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! )
I never just tell the customer something like this - I always write it down first. If they don't understand or misunderstand and pass the wrong info along it's going to come back to you - "That's what the developer said." Now you waste more time (and rep) untangling the mess. Best is to write a quick explanation of the problem and a add couple possible approaches to resolution.
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.
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.
Yes, and if you are a high caliber presenter, you would also know your target audience.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
If you rifled through your company documentation guidelines you would probably find I am bang on target. It was probably added to the policy over a weekend - making it a Saturday night special. Note that it is in the 2nd amendment of the documentation.
(Sorry if this post has triggered anyone. (Well - not really!))
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)