Introducing The Blame Game
4March 26, 2018 by Kenneth Fisher
Introducing the Blame Game! Someone has messed up the new anatomy application’s (Mr. Body) performance and no one is willing to fess up. It’s up to you to place blame where it’s due.
8 Characters you’ll recognize from your own meetings.
6 Mistakes you’ve probably made (more than once).
10 Locations you’ve worked with.
It’s Monday morning and your manager Brent has called his usual emergency all-employee meeting. He looks more than a little bit unhappy, and this time it’s not because someone stole his cruller. Over the weekend he was demonstrating the new anatomy program Mr. Body to some investors and frankly the performance was miserable! Now Brent has only one question.
SQL Studies 
Okay first we have the people skills guy. He’ll use a couple acronyms incorrectly and talk about ubiquitous theology network issues. Then you have the fossil that’s related to a board member. He’ll ask some great questions about someone irrelevant. Then the helpdesk guy that “should be working on servers” that will ask if the network is down, or if we should reboot AD. Followed by the guy that babysits a single app and continues to swear this wouldn’t happen on Linux. The DBA that blames the server guy, the server guy that blames the DBA until they get on the same page long enough to blame the application developer. After these three have a kumbaya sit down, they’ll eventually blame either the network or the firewall. Enter the cheap consultant with a great line of BS. He’ll bill and make random, subtle hints at how he should have been hired. After no definite answer and a lot of bill time, he gets escorted off the property. After the manager with an MBA (and still spells it sequel in his updates) will google something unrelated and offer it a solution. He’ll bring in a moderately priced consultant that will put the database in single user mode, shrink all the files and go home to research. eventually the issue resolves itself when one of the DBA’s that recently changed his password, changes it in the SQL job (yet continues to use his login in the job) to reflect his password. The stats update, the queries recompile and the app stops timing out. And it works. Until the database developers who have been working on a new giant view used to import large amounts of data fire off the stored procedure, locks happen and we’re back to it locking and application time outs.
Very nice! And scarily accurate.
My turn… . It says “Timeouts in production…users lighting torches.” I roll and move 3 spaces and land in manager’s office. It says “Your manager asks why you wrote a query that is getting timeouts. Pay $50 and blame hardware or roll again and try to explain how dynamic environments work.”
[…] Kenneth Fisher has a board game for us: […]