Fast – When developers ask how quickly a piece of code needs to run, don’t say fast. Give them a finish line so that they can know when it’s time to move on. “This query currently does over 15mm logical reads. We don’t allow production OLTP queries that do over 100k logical reads – anything higher than that needs to hit the reporting server instead.” Developers don’t want to write slow queries, but if you don’t show them how to measure their queries, they don’t know what’s slow versus fast. Show them how to measure what makes a query successful, and they’ll start measuring it long before they bring it to you.
Sometimes – When code works unpredictably, don’t say it sometimes works. Look for things it has in common when it fails. Does it bomb every Sunday, or when it handles over ten customers, or when it’s only being called once at a time? Keep digging for environmental coincidences until we can give the developers or QA staff a lead. Sometimes (see what I did there?) I find that developers want access to the production server just because they can’t get enough specific troubleshooting help from the DBAs. “Your code fails sometimes” isn’t going to cut it.
Never – When the developer tries to deploy a trigger in production, don’t say, “We never allow that.” The business, not our emotional desire, dictates the technical solutions we use. We’re here to advise the business, and sometimes the business won’t go along with our advice. Our job is to lay out our concerns clearly and concisely, preferably with risk assessments and real-life stories, and then listen. I’d love to build every box and application perfectly, but we gotta ship if we’re going to keep paying salaries.
Fine – When you’re asked how the server is performing, don’t say it’s fine. Quantify it in terms of batch requests per second, average duration for a stored procedure, or some other metric that you can measure precisely. Bonus points if we correlate this number over time, like if we can say, “We normally average 1,400 to 1,500 batch requests per second during peak weekday hours, and we’re doing 1,475 right now.”
Large – When developers asks how big a table or database or index is, don’t say large. What’s large to you is small to someone else, and vice versa. Give exact numbers: number of terabytes in the largest database, number of databases, number of rows in the largest table, or the number of times you’ve updated your resume in terror because the backup failed.
It Depends – DBAs love giving this answer as a cop-out for tough questions, and if you’re not careful, it comes off as a condescending know-it-all. For best results, immediately follow this phrase with the word “on”, as in, “It depends on the table’s access pattern – in read-focused systems like our data warehouse, we can have up to 10-15 indexes on our dimension tables, but in OLTP databases like our web site, we need to aim for 5 indexes or less per table.” The faster you can help someone to the answer they’re looking for, the more they’ll respect you as a partner, not an enemy combatant.
17 Comments. Leave new
You forgot to mention the word Please. If DBAs said Please to Developers then they would start to look more humble and no one wants that. I’m both a DBA and a Developer so I consistently struggle being nice to myself.
Nice post. I think this also applies more broadly to discussions with our managers as well because they appreciate smart and concise communication.
I couldn’t agree more on the “It Depends” answer. In the community we scoff at that answer, but it’s perfectly viable so long as it is followed with what it depends on and how that can be measured. If I hear a speaker give that answer without the other pieces to the puzzle, then he/she loses some street cred. He/She gets bonus points though if they ask the audience who knows what it depends on.
Great article. Short, simple and accurate. Actually provided more value than it cost in time to read it; a rare treat.
What words SHOULD DBAs say to developers? I need a follow up post!
As another half-breed who’s worked both sides of the fence, I can tell you that would be a *much* longer article, with words like “cache” and “reuse” and “scale” getting used a lot.
Heel, sit & beg.
With the occasional ‘good boy/girl’ and a tummy tickle to keep them sweet.
Andy, I look at my pets and think they’ve got a sweet gig going on. Not sure if I want a tummy tickle from my boss though. Wonders if I can talk our part-time booth babe into giving me one…
Great post. Having walked both paths at some point or another, I’ve seen the value of good, clear communication.
I think a post about what Developers should never say to DBAs would be a good one as well.
As a developer, I’ve ran into environments where things DBAs take for granted (viewing SPIDs, blocks and wait times) is locked out to the developers. For knowledgeable developers, not having those tools can sometimes feel like you’re flying blind. In these cases, developing a good relationship with the DBAs is essential so they can answer questions like “Why’s this query taking forever when it finished in 2 minutes an hour ago? Is somebody else blocking me?”
I enjoy your blog and videos. Thank you!
As a network engineer on the path to becoming a DBA, this is quite informative. Any other articles to help translating our related but distinct languages would be great.
Ah the “it depends” answer. Trying to distill years of hard won knowledge down into a short enough explanation of scenarios such that they don’t use you as a cure for insomnia.
The rest of it is inline with SMART objectives. Specific, Measurable, Achievable, Realistic and Targetted.
Then there’s the size thing. Hard to state the DBA definition of “large” without sounding boastful or lacking in credibility. I made a bad mistake with someone senior when they were boasting about the size of their data warehouse. I misheard and asked if that was their test data.
I didn’t mean it nastily or in an attempt at a cheap put-down, its just that what a DBA regards as a large database or table is going to differ wildly from what a business person thinks of as a large database or table. Case in point I’ve seen a marketing person go all gooey over the thought of 1 billion records held on a particular subject area. I honestly don’t think he would have believed me if I’d told him some areas are nudging the trillion record mark.
I’m totally in awe of the volume of data going through the betting industry. They probably think my idea of large is just test data;)
Yes, one can strive to communicate clearly and concisely whether or not the listener is receptive. It can be challenging and at the end of the day we only have direct control of our own communication.
SMART is good.
I’ve always liked Jerry McGuire’s “Help me help you”. For the higher level conversations, “Speed, quality, price – pick two”.
I have seen some developers who, when they’ve see how to measure what makes a query successful, immediately adopt those measures,
Then I have seen many developers who choose to ignore those measures and focus on meeting functional spec and the deadline. Challenging indeed.
They are never old, they are always brand new. Those two little words, “Please” and “Thank you”.
(Ok, technically, there are three words, but it is a quote and since there was no specification documentated…..)
When I have a problem with a developer, I talk to the developer, if the enrivonment allows.
I don’t copy fourteen levels of management.
I show a little respect and I get respect.
It helps when the developer knows that I want to help him succeed.
What about the ever-insulting “It’s a limitation of the system…” response? I find that one most vulgar and indicative of a poorly educated DBA.
“I have never seen a technical problem that my teammates and I could not solve.” I say it early and often. It has the benefit of being true.
100% agreed with this, but I feel like you could go one step further, and remind people that, in the end, the DBA’s job is essentially one of customer service, with the “Customers” being the developpers or end-users of the application.
As a DBA, its your job to ensure that the database environment is running in a manner that does not impede with the end-users experience of their application. So, if the developper tells you that they need so and so table with such and such access, what you need to do is to find the best way that you can deliver that, while at the same time keeping the structure of the database such that you can expand on it in the future.
I very much dislike it when I speak with people in charge of databases and hear responses like “no sorry, we can’t do that” – if I’m asking about a feature that we need implemented, it’s not because I want to be told that you can’t do it – it’s because I want to be told that you can do it, here’s how long it will take you to get it done, and then leave it up to you to decide how to deliver it to me. Likewise, when someone asks me to develop a new application for them, I expect them to give me the specifications, and then leave it to me to decide how to develop it to deliver for them.
What I find entertaining is that even though the post shows a disconnect between dbas and developers, the same sort of disconnect is also there between programmers and non-programmers. For example, when developing anything, whether it’s front-end, back-end, or even web, non-programmers want it done yesterday, and think you can program something to do anything under the sun. “What do you mean you can’t do that?” or “why do you need more than a week?” are awesome to hear at 930 in the morning.
How about NO? Whenever I see a developer walk towards me, my immediate reaction is NO! ?