There’s a 6-Month Statute of Limitations on “The Last Person.”
“The last person must have set it up that way.”
“The last person wrote that code.”
“The last person just didn’t configure it right.”
You can use that excuse for 6 months.
For six months, you’re allowed to get up to speed on the company’s politics, the intricacies of the app, and the responsibilities of different departments. You’re allowed to prove yourself to your peers, building up social capital so that they’ll take your recommendations and run with ’em..
You can take your time figuring out whether the last person knew what they were doing or not. You should start by assuming that you did, and give them some benefit of the doubt because they were under time pressure just as you are now. If you’re generous and curious, you can even try to contact them through unofficial channels, offer to buy them lunch, and chat about their experiences at the company.
But after 6 months, the statute of limitations is up.
After that, you’re not allowed to blame “the last person” anymore.
The last person can no longer be prosecuted for their crimes against the database, and they are absolved of any guilt. It doesn’t matter who was originally responsible last year: the person responsible is now you.
So pull yourself up by the bootstraps, write up a health check with sp_Blitz, and start working through the problems. Put the correct backups and corruption checking in place. Schedule that outage. Apply the patches. Fix those linked servers using the SA login.
Because after 6 months, if you’re not fixing these problems, the clock is already starting to tick down to when you will be referred to as “the last person”, and they’re going to roll their eyes when they talk about your inability to get the job done.
Just like you’ve been doing about “the last person” for over 6 months.
27 Comments. Leave new
2018 feels like 6 months ago sometimes. It also feels like 20 years ago at the same time.
You beat me too it. One last SQL 2014 server to upgrade (unless something else if found)
Security came to the rescue with “Please sign here saying you confirm to pay the costs of any post hack remediation.”
I remember looking forward to SQL 2012 back in 2011 – which does not seem that long ago.
Nice theory. There are always the stealth databases and servers that only get used at end of year or for some reason like the annual audit. In practice I’ve seen that excuse work for the day you arrive and you’re expected to “earn your spurs”.
PS: Nothing like finding out someone has their “off the radar” server under someone’s desk and it just gave out.
In theory, I agree. But when I started my current DBA job, I was given an employee badge, a desk, a phone, and a PC and told to “figure it out.” The last database server I discovered was almost a full year later. I’d just stumble across new DB engines from time to time. Very frustrating, since none of them were configured well or backed up properly at all when I found them. “The last guy” was working in another division of the company, but he refused to reply to emails requesting details. I literally had to resort to port-scanning the server IPs to track down the DB servers.
Wow! I’m trying to imagine how broken an environment has to be to lack even basic documentation about their servers. Insanity.
Charles – that isn’t a new problem. It doesn’t take 6 months to run a port scan. That was literally one of the first things I did when I took on a DBA role back in the 2000s.
“Six months to recommend a fix” It may take a year to implement but yes.
Sadly I live in “vendor limbo” where somethings can not be changed.
No on site hand crafted code here – it all comes from “Elsewhere” [which rhymes with vapor ware”
It pays the bills.
You beat me to it….
There’s been sites and roles where SQL Server is so far behind that the version is out of extended cover, yet, due to the pandering to vendors. There’s a wide-held statement in government that you’re not allowed to annoy the vendors lest they drop that site from the product and support. This is a thoroughly stupid comment as no vendor is going to drop a customer when they’re being paid anywhere in the region of $120,000 -to- $180,000 a month to refuse to supply upgrades to their poorly-performing database environment.
TechnoCaveman – that’s fine, but you don’t get the right to blame the last person for years. You chose the job, you’re cashing the checks, and you’re on the hook now.
If we can’t blame them, can we at least occasionally take their name in vain? After 10 years, I still curse The Vendor That Shalt Not Be Named when I try to add a new feature to their spaghetti-code application. Management won’t allocate the time/money to refactor/rewrite/replace the app (even though everyone on the dev team has recommended it), There’s no six-month limit on blaming management, right? 😉
I wholeheartedly agree with the general take-responsibility-instead-of-assigning-blame philosophy (at least in the abstract) but have to disagree in practice. I took over at a previous job for someone who may have been one of the most inept programmers I’ve ever encountered, and was discovering his “innovative” approach to coding squirreled away in various places and company systems for years afterward. I grew accustomed to his way of thinking (generously applying that word here) and could patch things up pretty effortlessly after a while, but still… the blame belongs where it belongs.
On the bright side, coming into that kind of situation and cleaning up after someone else’s sloppy coding is actually a great learning experience. It was frustrating and instructive.
You also get six months to blame the new person.
Nope. I’m on a team, and when something is bad, I fix it. No blame assigned, we just fix it and move on.
Might discuss it internally amongst ourselves about a better way of doing it.
That’s the right way to go!
Blaming your predecessor is a popular part of our culture when people don’t want to take responibility. It’s easier to say this is messed up because of the last guy, rather than say, here is what we have, and here is what we are going to do about it. One day I plan to be the “last guy” myself. At least I won’t have to hear what is said in my absence.
As long as this Statute of Limitations is restricted to just those DBA items identified by spBlitz, that sounds reasonable. But if your job encompasses all roles (DBA, Data Architect, etc.) and you are assigned many databases — or just one huge mess of a database — then I’d say you likely need a lot more time.
I’m talking about terrible design patterns including, but not limited to, very wide tables, heaps, repeating groups of columns, multiple values stored in one column with a delimiter, etc. These all lead to sloooowww experiences for the users, but often times changes need to be in sync with application code changes that require change board approval. In that case, six months is a fantasy dream!
Tom – you can take on more, but you don’t get to keep blaming “The Last Person” for years. It’s yours now. Buckle up and own it.
I always did buckle up, but sadly I did not own it. Corporate IT got to make all those decisions, with contract employees staffing IT for the most part. I’m retired now. Fortune 100 company. Not easy to implement recommended changes, when there are too many chiefs.
We have areas of code that are old, and are not as nice as we’d like them to be, but the thing they all have in common is that they don’t cause any issues that are worth reacting to.
The last person named that table
tbl_shipping_label.The last person forgot/remembered to define foreign keys there.
The last person set that index’s fill factor to 90.
So there’s no blame to go around, it just becomes a bit of interesting history.
Oh, also, after X years at the same place, *I’m* often the last person (good or bad).
Sometimes I blame younger-me, but (like you) I also blog for younger-me as an audience too.
In my company, it was like, “I did not code that originally but we can fix it”. We only chide folks who commit terrible acts that bring down or degrade production operations. Six months of blame was not acceptable, which is nice even when I was the one who may have committed the crime. Once in a while you will hear “remember when the accounting DB server was unusable because you did x”. Then we laugh, even though we were up all night diagnosing and fixing the issue.
This is from a onetime DBA and now an architect and developer with emphasis on data layer optimization.
Interesting perspective on the blame game in tech. As a DBA, I focus on finding solutions and working collaboratively to prevent future issues. Strong communication and proactive monitoring are key to preventing problems from snowballing.
[…] There’s a 6-Month Statute of Limitations on “The Last Person.” (Brent Ozar) […]
But the last guy is secretly just me. Per this oldie that I still find oddly relevant https://www.brentozar.com/archive/2012/10/learn-speak-dba-slang-terms/
You can tell a manager wrote this blog
You can tell our worst employee wrote this comment 😉
Haha, yeh why not, it works for Governments and they go back years. It was the fault of the last administration, we are still trying to fix it so vote for us again, so that we can continue the good work.
I usually give people the benefit of the doubt, people are not entirely stupid and nobody knows everything…
No DBA has any dang clients who give one bleeding flip about the “why” of why they don’t have their data. Round-file the excuses and fix.