Ed Wagner (9/27/2016)

---

Michael L John (9/27/2016)

---

Phil Parkin (9/27/2016)

---

Brandie Tarvin (9/27/2016)

---

SET RANT Brandie ON;

I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.

Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?

Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.

I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.

SET RANT Brandie OFF;

I assure you that you are not alone in having to do this!

DBA=Doing Bout Anything

Brandie, Phil is absolutely right - you aren't alone. Better yet, when the "official business rule documentation" that the BU wrote is wrong and horribly out of date, it's our fault when production code doesn't do what their documentation says it should do. The fact that they're the ones who requested the 35 changes and didn't document it is immaterial.

Another meaning for DBA is Default Blame Acceptor, so the fact that other people don't maintain their documentation is clearly our fault.