T-SQL & Development
I Hate The Way You’re Using “It Depends.”
Can I be honest with you for a second?
It makes my skin crawl when I hear database people smugly answer a question with “It depends!”
Because most of the time, when they do it, they chuckle as if they know something, and as if what they just said illustrates what an awesome expert they are. They elbow their DBA buddies, who also scoff and nod because they’re in on the DBA joke too, and they all feel superior to whoever asked the question.
And they sit there like the conversation is over, like they’ve finished their answer. They expect the questioner to just be satisfied with their ignorance, and to feel dumb for thinking that database administration ever has a clear answer for anything.
That’s bullshit.
If you say “It depends,” you have to finish the sentence.
Exactly what does it depend ON?
If you don’t finish the sentence by explaining what it depends on, then you don’t know the answer, and you’ve done the questioner a disservice by belittling them and ignoring their question.
You don’t have to give the complete answer in one sentence, but you have to finish the sentence. Examples include:
- “It depends on whether we’re talking about a table with 100 rows, or 100 million rows. How many rows are in this table?”
- “It depends on whether this query runs a few times per minute, or once a day. How often does it run?”
- “It depends on whether you need a short-term fix within an hour, or if I can get a few days to put together a solution that will last us at least a year or two.”
- “It depends on how many indexes this table already has – how many does it have?”
When you finish the sentence, you keep moving quickly towards a solution, and you’re a helper rather than an obstacle. Don’t be an obstacle: don’t be yet another reason why developers hate database administrators. <sigh> And if you need help understanding what it depends on, check out my training.
Free, 3× a week
Get my new posts by email
Three posts a week, plus a Monday roundup of the best database news from around the web.
In a similar vein, whenever someone says that some setting unequivocally has one correct setting, I like to play the “what’s that knob for?” game. Things like AUTO_CLOSE come to mind. I usually grant that it’s often the case that the knob in question has a setting that is correct for most situations. But to say that it’s wrong unless it’s set a certain way? Miss me with that.
“But to say that it’s wrong unless it’s set a certain way? Miss me with that.”
Counterexample: AUTO_SHRINK is wrong unless it’s turned off.
Get a load of this: I’ve actually seen a good use case for it! I know, I wouldn’t think it would ever have happened either, but here we are.
Had a client who found a 1TB logging table in a 2TB database. They truncated it, fixed the app to only keep a small amount of history in it. They wanted to move to Azure SQL DB, and they needed to get the database size down first to cut their costs & migration time.
They weren’t in a rush, and they didn’t want to deal with writing a job to shrink when the app wasn’t busy, so they just turned on auto shrink and let it happen gradually in the background. Made perfect sense.
Many DBAs have proposed that Microsoft deprecate (and eventually remove) Auto_shrink. Having encountered that client, do you subscribe to this position?
I haven’t seen a popular Feedback request for it. Have you seen one?
I think the most obvious example of a proposal would be from Paul Randall, made internally to Microsoft. Quoting him:
In terms of actual feedback requests, these only live on the now defunct Microsoft connect platform; I think all the big players gave up on submitting new requests, since Microsoft explicitly rejected requests to remove/deprecate it.
My friend can confidently say that in a few enterprise organizations, finishing that sentence is considered insubordination.
They don’t want actionable words at the end of the sentence because that then implies a decision has to be made. And a decision to be made invites all kinds of things like thinking and accountability.
However being snooty about ‘it depends’ isn’t better.
I agree whoeheartedly, Brent. “It depends” by itself is not an answer, it’s a dodge.
I’ll say “it depends” when someone is repeatedly speculating about things that will never happen or they have no idea what they are talking about.
No specifications or details? That’s fine, me saying “it depends” in those case is a neat way of saying “get back to me when there’s some meat on that bone”.
This is a good point. If someone is speculating and trying to get some end-all answer without offering any details/specifics/end-goal – “it depends” does seem to be a valid answer. Now I still might qualify that with some other thoughts about some bigger picture what it might depend on, but I still try to throw that ball back in their court to get those details and then let’s talk.
I’ve had the same thoughts for years and thank you for writing about this. With that said, despite our faults as a community, we still seem to be doing much better than the folks at Stack Overflow. I recently had a “Principal Software Engineer at Microsoft” complain at me over there because I answered a question that was a few years old.
Completely agree. It depends is not followed by a period.
I love that! Very concise.
I will admit to using the phrase quite a bit over the years, but I do try to follow that up relatively quickly with the “what it depends on”. Could we solve that problem with a linked server? Yeah – but is that the best solution? Maybe. Maybe not. Should we use PowerShell? Again – what are you trying to do? And even though I generally like SSIS, it does depend quite a bit on what you’re doing as to whether it’s a good fit for the problem at hand. Now if someone throws that at me – I’m likely to follow up with the “what does it depend on” when I just don’t know what to do next and am seeking that guidance.
Regardless, this is definitely something to watch for when chatting with customers/users.
Thanks, Brent! This lines up with what I’ve long said: DBA should also stand for Don’t Be an A$$hole.
I’m convinced that the roots of the NoSQL movement can be traced to DBAs being vague, stretching delivery dates, or outright obstructionist.
You sir, are CORRECT. I know this from first hand experience with MongoDB. The company I worked for in 2008 brought in MongoDB for what I thought was a very good use case where SQL Server/relational modeling wouldn’t work well. Their value prop slide said, “No DBA needed, no schema needed, no indexes needed, no backups needed”.
I immediately had the AHA moment. That is PURE GENIUS from a marketing perspective. We all know it’s complete bs but they were selling directly to the biz stakeholders that were tired of DBAs being “the department of NO or it depends” and to the devs who viewed the DBAs as “those people that ask questions we don’t have the answers to”.
Then, 7 years later, a certain cloud vendor I worked for released their own NoSQL-as-a-Service. What was the value prop? “Migrate your on-prem SQL Servers to this PaaS offering and you won’t need to worry about DBAs, indexes, backups, schema.” Admittedly it’s a small sample size, but I never ONCE had a customer successfully migrate. However, I did have a lot of engagements around “whoa, this thing we migrated to costs a metric ton to operate. you better fix this or we’re migrating to your competition.” Appalling.
“It depends.” can never be the whole answer. The phrase is just an indicator that there is a longer answer coming. So if the phrase is not followed up by an explanation its like stopping midsentence. So if there is no medical reason for not giving a longer answer than you are just rude and you are (part of) the problem and not part of the solution.
In the interview for my first role as a “real” DBA, I was asked “what’s the difference between a DBA and a terrorist?”. As this was the olden days, and I was coming from a shop with no real DBA from whom I could learn real DBAs weren’t there to assist , I didn’t know the answer. But right then and there I knew that was the sort of DBA I did not want to be. For me, “it depends” was a joke where only one person in the room was laughing, which in reality, makes it a non-joke, or just plain nasty.
“DBAs don’t negotiate” was the answer. That attitude would not get you a job in anywhere I have worked since.
HAHAHA, wow. I’ve known some teams like that for sure. I’ve heard DBA stands for Don’t Bother Asking in some shops.
This reminds me of an ex-colleague from a long time ago. He was all too fond of saying “this is shit”. I pointed out to him that you can only get away with doing that if you follow it up with why, what can be done about it, and how long it’ll take / how much it’ll cost to get out of the ordure.
And here we go again… Brent slaughtering another sacred cow in the town square.
HAHAHA
OMGoodness the arrogance. I find that such a condescending response. You’re right — just respond properly and don’t be jerk about it.
I don’t know Brent, it depends.
GROAN
(giggle)
It depends, what problem are you trying to solve?
It’s a very useful phrase, I even used it as the title of my blog. It’s true. It does depend. Always. On something. Thanks for calling out that recognizing that is step one of the process, and explaining the things it depends on is what makes you useful to the problem solving process.
Two way street. Customer service is a must. At the same time one gets as much information from a question as he himself is willing to provide. I can ask probing questions, but help me help you.
The really interesting thing is that our dad joke of “it depends” often goes over the heads of folks who’ve never really been through the concepts of normalization, so we’re not even as funny as we think we are.
We just sound like smug jerks, and don’t even realize it.