January 30, 2020 at 4:46 pm
I don't think it's so much of a manual vs. automation issue. Wherever I've been a DBA I've tried to automate as much as possible so that I could eventually focus my time on more valuable aspects of my job.
Delegation can be useful, when there is someone capable to delegate to, but in places I've worked at there is often a shortage of people who really know or want to know the database side of things.
January 30, 2020 at 4:48 pm
I've also literally seen 3 people die because of bad decisions that I warned them about. .
so many points in your post jeff that I resonate with - in 2000 as a developer I spotted a flaw on a railway inspection system that cost many many millions of £££££ (last time I checked it was 400 mill)
the project was so bad that we had to use access and SQL to work around the issues in the COBOL/Oracle mess that was being delivered by our government paid providers.
A train was derailed at Hatfield that killed 4 and injured 70. if my changes had been put in then the track would have been repaired and no-one hurt.
Luckily when the Auditors came sniffing, I had already put in the system (before the accident) and just not told anyone (it was just 2 extra columns - original date, original priority) suddenly the focus was not on IT and app dev, but on the people who said "no" to my suggestion.
I still had to take a bit of time off work for stress, and at 22 years old you have no experience of dealing with the responsibilities of being a DBA where lives are at risk.
Now I work in marketing... the only thing at risk is that we double book the underwear models 🙂
MVDBA
January 30, 2020 at 4:51 pm
...I am convinced that this is a personality type issue. Really good DBAs almost always have this very annoying attitude. Members of the development team--something very different from that...
I don't think it's as much an attitude issue as it is a domain knowledge issue. I wouldn't try to tell .Net developers how to write C# code, but I've found no shortage of .Net people over the years who either are unable or unwilling to understand that there may be a better way than their way to do data storage and retrieval. Sometimes even if you explain the consequences of their decisions and design they are unwilling to change their mind. So even though developers may perceive that they are the good guys, my experience tells me it goes both ways.
To really get things accomplished in a productive environment, both sides need to be willing to discuss it and respect the domain of other parties involved.
January 30, 2020 at 5:02 pm
GeorgeCopeland wrote:...I am convinced that this is a personality type issue. Really good DBAs almost always have this very annoying attitude. Members of the development team--something very different from that...
I don't think it's as much an attitude issue as it is a domain knowledge issue. I wouldn't try to tell .Net developers how to write C# code, but I've found no shortage of .Net people over the years who either are unable or unwilling to understand that there may be a better way than their way to do data storage and retrieval. Sometimes even if you explain the consequences of their decisions and design they are unwilling to change their mind. So even though developers may perceive that they are the good guys, my experience tells me it goes both ways.
To really get things accomplished in a productive environment, both sides need to be willing to discuss it and respect the domain of other parties involved.
+1,000,000 to THAT!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2020 at 5:41 pm
I don't think it's as much an attitude issue as it is a domain knowledge issue.
Maybe you are right but I think there is also a cultural issue. A good default pose for a developer might be as a collaborator who wants data to be "free". In my experience, this is not a good pose for a DBA at all. I prefer a DBA who is more like, Shut up and get out of my office until I have my coffee. Collaboration might seem rocky, but I have noticed that production support in an operation like this tends to be a lot smoother.
Edited to be more specific about the role of the DBA on a software development team: DBAs end up being responsible for data governance. There is no getting around this fact. When the auditor comes in with a social security number and says, I want to know the names of every person who had access to this data, I highly recommend that you have an answer to that question. "But but data wants to be free," that is not going to cut it.
January 31, 2020 at 6:49 pm
Maybe you are right but I think there is also a cultural issue. A good default pose for a developer might be as a collaborator who wants data to be "free". In my experience, this is not a good pose for a DBA at all. I prefer a DBA who is more like, Shut up and get out of my office until I have my coffee. Collaboration might seem rocky, but I have noticed that production support in an operation like this tends to be a lot smoother.
In my limited experience as a DBA, some developers aren't happy until they can access anything they want in any production environment, even if there is a perfectly fine test/stage environment that they already have access to. Theres been many times in my last year and a half where we've said no, you can't have access to this prod environment only to have the person go to their director who then complains to the VP and they end up getting what they want in the long run(its a relatively small company). Honestly, I can really understand why so many DBAs come off as jaded when it comes to this type of thing.
January 31, 2020 at 7:12 pm
Oogibah, tough situation. I usually try to keep my advice positive. Unfortunately, my experience makes me pessimistic about the business viability of your company.
January 31, 2020 at 10:17 pm
When the business overrides you, there really isn't much you can do. Education is key. However, I'm still very much on the side of being part of the team rather than an outside force dictating what, why & how.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 31, 2020 at 10:57 pm
GeorgeCopeland wrote:Maybe you are right but I think there is also a cultural issue. A good default pose for a developer might be as a collaborator who wants data to be "free". In my experience, this is not a good pose for a DBA at all. I prefer a DBA who is more like, Shut up and get out of my office until I have my coffee. Collaboration might seem rocky, but I have noticed that production support in an operation like this tends to be a lot smoother.
In my limited experience as a DBA, some developers aren't happy until they can access anything they want in any production environment, even if there is a perfectly fine test/stage environment that they already have access to. Theres been many times in my last year and a half where we've said no, you can't have access to this prod environment only to have the person go to their director who then complains to the VP and they end up getting what they want in the long run(its a relatively small company). Honestly, I can really understand why so many DBAs come off as jaded when it comes to this type of thing.
Stating the obvious but have to say it out loud, the Director and the VP you're talking about need a bit of, ummmm... (trying to stay a bit PC) "calibration". I'm afraid the only way that they're going to learn is to have something go horribly wrong. Make sure that you've fully documented this incident and sent you home email a copy so that you're not left holding the bag when it eventually happens. I'd also anticipate the impending disaster and make sure you have a recovery path at the ready for the servers.
Like I said, you already know all of that but had to say it out loud if, for nothing else, to commiserate with you on this awful situation. Serious well wishes go out to you on this.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2020 at 1:39 am
When the business overrides you, there really isn't much you can do. Education is key. However, I'm still very much on the side of being part of the team rather than an outside force dictating what, why & how.
Hi Grant, I have been pondering your comment. I have to tell you that I find it extremely wise and insightful. Looking back, I can honestly say that every time that I have depended on my team, they have never once let me down. Yours is a great way to live and to act. Thinking about Oogibah's issue as a teammate for a minute, I think my approach would be to try to educate management that developer workstations are security holes, because of the network access they are granted and the programming tools installed. Instead of providing more access to production, it makes much more sense to reduce it. Doing this could be a win for everyone.
February 1, 2020 at 3:16 am
Grant Fritchey wrote:When the business overrides you, there really isn't much you can do. Education is key. However, I'm still very much on the side of being part of the team rather than an outside force dictating what, why & how.
Hi Grant, I have been pondering your comment. I have to tell you that I find it extremely wise and insightful. Looking back, I can honestly say that every time that I have depended on my team, they have never once let me down. Yours is a great way to live and to act. Thinking about Oogibah's issue as a teammate for a minute, I think my approach would be to try to educate management that developer workstations are security holes, because of the network access they are granted and the programming tools installed. Instead of providing more access to production, it makes much more sense to reduce it. Doing this could be a win for everyone.
+1000!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2020 at 9:58 am
In my limited experience as a DBA, some developers aren't happy until they can access anything they want in any production environment
I have gone through this and the question to them is "What problem are you trying to solve? Articulate the problem, not the solution"!
I've seen a lot of "solutions" that were worse than the problem they tried to fix. I've also seen "solutions" that added complexity because they looked like convenient quick fixes whereas the actual solution looked to be hard work and/or complicated. The latter needed to be implemented once and the problem would be solved for ever. The former provided a short term partial work around that bit us on the bum time and time again
February 1, 2020 at 12:34 pm
In my limited experience as a DBA, some developers aren't happy until they can access anything they want in any production environment
I have gone through this and the question to them is "What problem are you trying to solve? Articulate the problem, not the solution"!
I've seen a lot of "solutions" that were worse than the problem they tried to fix. I've also seen "solutions" that added complexity because they looked like convenient quick fixes whereas the actual solution looked to be hard work and/or complicated. The latter needed to be implemented once and the problem would be solved for ever. The former provided a short term partial work around that bit us on the bum time and time again
Okay, here's my +1000!
All to many times someone comes to me with a solution that doesn't make any sense instead of the problem and i go back to the same question. 😀
February 1, 2020 at 1:17 pm
This was removed by the editor as SPAM
February 1, 2020 at 2:38 pm
I don't think it's as much an attitude issue as it is a domain knowledge issue. I wouldn't try to tell .Net developers how to write C# code, but I've found no shortage of .Net people over the years who either are unable or unwilling to understand that there may be a better way than their way to do data storage and retrieval. Sometimes even if you explain the consequences of their decisions and design they are unwilling to change their mind. So even though developers may perceive that they are the good guys, my experience tells me it goes both ways.
To really get things accomplished in a productive environment, both sides need to be willing to discuss it and respect the domain of other parties involved.
Is it really a good strategy to cooperate? The other side opposes set based solutions as a matter of practical policy. To many, many developers RDBMS are a temporary expediency which will soon be soon replaced by something "faster, easier, and better." The opinion of non-Sql devs about Sql (in general) is basically worthless. Most of them tried to learn Sql and failed. So instead they obstruct, undermine, and further the prejudiced circumspection against sets. My fightback is a data access framework which is an "Anti Entity Framework." Instead of attempting to make data access an automated implementation detail of procedural server code it does the opposite. It makes the server code an automated implementation detail of the database code. That's my answer to the deluded rbar'ers.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply