October 27, 2016 at 10:25 pm
Comments posted to this topic are about the item Emotions and Decision Making
"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
October 28, 2016 at 1:51 am
I've learned to ask why a particular response occurs and to keep drilling down until I get to the root cause. In architecture this is called the five whys.
Why don't I like ORMS? Because They throw abominations at the database
Why do they throw abominations at the database? Because they are not configured correctly
Why aren't they configured correctly? Because they are seen as a quick fix?
Why don't you help configure them? Because the team using the tool have been granted permission to use it and see it as a way of eliminating the need for a DBA.
Why do they want to eliminate DBAs? Because I get blamed for saying NO. They see me as a blocker.
Why do you say NO. Fundamentally the principle of "Data is Shared". My job is to ensure that all data users be they apps or people get continuation of service. Some things may work fine for a small group but fundamentally compromise another groups activity.
The root cause for me is I don't want to be blamed for something I have no power to alter or control.
Database performance problems are a DBAs problem and nothing to do with developers, right?
Sometimes getting blamed has implications beyond mud slinging. Sometimes it ripples through to annual performance reviews.
The cloud thing is much the same.
Why don't you like the cloud? (Actually I do) Because the company is using a public cloud provider
Why don't you like a cloud from a public cloud provider? Because it is a shared environment to which persons and organisations unknown to me have access?
Why is public access a problem for you? Because I worry about database security?
Why don't you take steps to secure the database? I do but my area of expertise is the database and not in networking and infrastructure so I can only look after my layer.
Why do you worry about database security? Because I am not convinced that the environment in which the database resides has been configured and secured properly.
Why don't you think it has been secured properly? Because the cloud is seen as a quick fix?
...etc
So no, ORMs are inherently bad and the cloud isn't evil. They are tools with very sharp edges and need to be used properly and carefully. The evidence of experience suggests that the time and resources to do stuff properly is rarely granted. In my experience developers and DBAs both want to do the right thing they just might not know what the right thing is or have access to something that will teach them the right thing.
God bless the guys at Stack Overflow
October 28, 2016 at 1:53 am
Grant is right. We should always be trying to arrive at a balance point using reason. Emotion is bound to play a part, but we should try to apply real logic.
A problem we all face is that, as technology changes, the balance point shifts, sometimes in one direction, sometimes in another. We should recognise the value of past experiences (otherwise we cannot learn from them) but we need to recognise that they may be misleading us too.
Looking at my own prejudices, I think that when I was younger (and only knew one way to do things) I would either prefer the way that I knew or be desperate to try the next, bright shiny new thing. I suppose you could call those "positive prejudices". As I got a little older, and had had a few unpleasant experiences, I tended to have to shy away from repeating them - "I don't want to repeat THAT again". You could call that a "negative prejudice". As Grant suggests, both of these can lead us to make wrong decisions for emotional reasons. I need to fight any tendency I have to be "a general fighting the last war" (whether I won or lost last time).
Another issue is that many "business systems" outlive the technology which was considered, or fashionable, or used to develop them when they were created. I guess that is something to debate another day.
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
October 28, 2016 at 2:01 am
Oh yes! I like the "5 Whys?" (or however deep you want to go). That's a really good way of challenging your own prejudices. 🙂
And also, yes - some of the tools we use (like ORMs and "The Cloud") are very sharp. That is a good thing - every good workman likes good (sharp) tools, but can also be a bad thing because sharp tools can be dangerous in inexperienced hands or when used inappropriately. 🙁
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
October 28, 2016 at 2:34 am
I really enjoy utilising new technology but as a mature developer I have one fundamental question when a team (including me) wants to roll out new tech:
After the team is disbanded and completion of the project, how will this new tech be supported and by whom?
If this can't be answered to the satisfation of both the development and the management teams then quite simply it should not be used.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 28, 2016 at 6:12 am
Gary Varga (10/28/2016)
I really enjoy utilising new technology but as a mature developer I have one fundamental question when a team (including me) wants to roll out new tech:After the team is disbanded and completion of the project, how will this new tech be supported and by whom?
If this can't be answered to the satisfation of both the development and the management teams then quite simply it should not be used.
I agree so much that there isn't a number high enough to express it.
On a wider note what this is describing are NFRs (non-functional requirements) which are frequently NSRs (non-stated requirements) that turn out to be the most important requirements of all.
October 31, 2016 at 2:25 am
I have two points, one is the argument of new versus old: if a technology works fine, what criteria must the new technology have in order for it to supercede the old technology? Or must the parent company drop support of it in order to promote the new, shiny thing?
And the second is the place of DBAs within both the general scheme of things as well as within the company in specific: where does the DBA figuratively live?
One developer who works with us is of the opinion that DBAs should be in charge of the DAL (Data Access Layer). This means that they are responsible for learning C-Sharp and Dot-Net, and if they don't, then they have no right to complain about the developers using LINQ and Entity Framework.
I really, really don't like LINQ code from an optimisation viewpoint but I am obliged to accept that it does save the developers a lot of time. I have posted before that it is a theft by the developers of the DBAs' time (optimisation becomes a lot harder when you are dealing with 100+ lines of LINQ code). This was an emotional response. What kind of decision do I make based on this turn of events: fight for DBA-control of the DAL? This is a lot of work and we would have to learn C# too. There is so much more in SQL Server than I would like to master. Cede responsibilty of optimisation to the developers (which means that it will never be done)? Suck it up?
October 31, 2016 at 3:25 am
Sean Redmond (10/31/2016)
(Point 1): if a technology works fine, what criteria must the new technology have in order for it to supercede the old technology? Or must the parent company drop support of it in order to promote the new, shiny thing?
That's a fair question. The risk with continued support for old products is that it sucks the life out of development. But on the other hand, I've seen support discontinued for things which are working fine simply to force customers to move to (and buy!) new products. Whichever side of the fence you find yourself on, the NEW product should be providing most of the function of the old one, the NEW product should be providing something extra and someone should have some idea how to bridge the gap between them. Not easy at all!
Sean Redmond (10/31/2016)
(Point 2): ...One developer who works with us is of the opinion that DBAs should be in charge of the DAL (Data Access Layer). This means that they are responsible for learning C-Sharp and Dot-Net, and if they don't, then they have no right to complain about the developers using LINQ and Entity Framework...
I suppose the point here is that if we are to make reasoned decisions, then SOMEONE should have an idea how the overall system fits together. We should be trying to optimise the overall effort/cost we put into creating and maintaining things. (I was tempted to put "minimise", but I don't think that is truly possible). Without either an over-arching "Technical Authority" (or whatever you want to call it), or the different parties knowing a little about what goes on on the other side of the fence then it is always going to come down to an emotional decision and who shouts loudest. In the long run that usually means either stagnation or systems which cannot be maintained.
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
October 31, 2016 at 5:56 am
From the Article: The emotional baggage we tie to technology leads us to poor choices.
I DO wish that people on [font="Arial Black"]BOTH [/font]sides would remember that! Frequently, and speaking of voting, management makes the mistake of taking the di of the crowd for the wisdom of the group. If you have a DBA, remember that they're supposed to protect the data while still ensuring access to it and also remember that they're frequently a single voice because there's frequently only 1 of them.
Frequently, a DBA is "out-voted" by a group of programmers that, although usually well intentioned, don't know much about databases and THAT'S not good for the servers, the data, the people that work for either, the customers, and certainly not for the company.
Listen to your DBA(s)... it's the reason why you hired them and stop chastising or even accusing them for being emotional. They're not the only ones being emotional but are probably the only ones that deserve to be because their heart and soul is into protecting the company from other emotional decisions. And, most of the time, when the SHTF, it's the DBA being left to pick up the pieces because every knows that [font="Arial Black"]<sarcasm ON> [/font]everyone knows that it's the database that's the problem [font="Arial Black"]<sarcasm OFF>[/font], right?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2016 at 7:13 am
Sean Redmond (10/31/2016)
I have two points, one is the argument of new versus old: if a technology works fine, what criteria must the new technology have in order for it to supercede the old technology? Or must the parent company drop support of it in order to promote the new, shiny thing?And the second is the place of DBAs within both the general scheme of things as well as within the company in specific: where does the DBA figuratively live?
One developer who works with us is of the opinion that DBAs should be in charge of the DAL (Data Access Layer). This means that they are responsible for learning C-Sharp and Dot-Net, and if they don't, then they have no right to complain about the developers using LINQ and Entity Framework.
I really, really don't like LINQ code from an optimisation viewpoint but I am obliged to accept that it does save the developers a lot of time. I have posted before that it is a theft by the developers of the DBAs' time (optimisation becomes a lot harder when you are dealing with 100+ lines of LINQ code). This was an emotional response. What kind of decision do I make based on this turn of events: fight for DBA-control of the DAL? This is a lot of work and we would have to learn C# too. There is so much more in SQL Server than I would like to master. Cede responsibilty of optimisation to the developers (which means that it will never be done)? Suck it up?
That's a very hard question to answer. I don't agree that a very strict definition of what a DBA is includes the DAL. However, as a DBA who came out of programming, what I did, as soon as I saw that our developers were going to be using nHibernate and Entity Framework, I went and learned the basics. I wrote a bunch of code (admittedly sub-standard code) so that I could understand what these things did and how they were being taught and implemented. I found the anti-patterns that would lead to problems. I documented all this for our dev teams. One team didn't listen and had a failed project because of it. One team did listen and had a wildly successful project, followed by more. It really came down to two things, I reacted with reason and research, not emotionally, and one of the dev teams did the same. The team that rejected my input did so because "it's just another example of the DBAs saying No", which was an emotional response, not one based on evidence.
So yeah, I don't want to own the DAL, but I feel that I should have feedback on how it is properly implemented since it has so much impact on the databases, which are under my management. The most important thing is to work with the teams cooperatively, and yeah, non-emotionally, to arrive at a good decision that both can live with.
"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
October 31, 2016 at 7:17 am
Jeff Moden (10/31/2016)
[font="Arial Black"]<sarcasm ON> [/font]everyone knows that it's the database that's the problem [font="Arial Black"]<sarcasm OFF>[/font], right?
Not at my old company. They actually had a running joke that "the database is NOT the problem" because I had said it so frequently and so vehemently that they usually investigated other issues before coming to me. The downside of that was that, when they did come to me then, it usually was the database that WAS the problem.
"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
October 31, 2016 at 7:20 am
The few development environments I've worked at always seem to have that one person that sways the crowd.
October 31, 2016 at 9:39 am
In most shops, trying to argue with application developers on the issue of proper database modeling and SQL coding is a lost cause. You'll just end up earning a reputation for being a grumpy old man.
However, one thing we as the DBA can do is approach the QA analyst and suggest that they incorporate database performance metrics into their test plan. We can help facilitate the process by supplying them with the proper scripts. We can also suggest various application usage patterns that we know ahead of time will introduce invalid data and errors, because we've already analyzed the data model in development and know where the weak points are.
When the deliverable falls flat in QA, we can then segue back into the picture and offer sage our advice on what the developers should do to fix it.
Yes, cool methodical maneuvering can be more effective than emotional arguing.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 31, 2016 at 10:25 am
Eric M Russell (10/31/2016)
In most shops, trying to argue with application developers on the issue of proper database modeling and SQL coding is a lost cause.
That's exactly why I got management buy-in the second day at my most recent job. They had several major performance, blocking, and deadlock problems and I fixed a couple on my second day on the job. I made the suggestion that no additional code go to production without me having a gander at it and they agreed. I'm usually also involved in the design aspects of things because I've demonstrated what happens when you have good design and pointed out that the bad designs were all a part of the problem.
I also realize that I'm fortunate to have a management team that "gets it".
You'll just end up earning a reputation for being a grumpy old man.
Heh... to be honest, I fully embrace and depend on such a reputation! Piss me off an I'll fill your car with cement! 😀 Well, not that last part. I've earned the reputation at work for not being afraid to speak up when it's needed and a quiet, helpful, and kind mentor most of the time. David Poole said it best a long time ago... to paraphrase, "If your the first person people seek out for database problems rather than the last, you might be an exceptional DBA".
It also helps that I work with a bunch of folks in management, Developers, and DAs that "get it". They had to be shown some of the advantages and disadvantages of how and why things work in databases but they "get it". If you lead with a bat instead of mentoring, they'll resist forever and they'd be right in doing so.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2016 at 11:19 am
On a project team a DBA just one member. My DBA responsibilities are negotiated at the beginning of the project. I'll match my rights and controls with the responsibilities and inform everyone what they can expect. Some nhibernate projects just want me to push structure changes to other environments. Some fat client projects want me to control everything. In other words, it is all just work and I don't care as long as a non-changing agreement is reached.
The biggest benefit of having a DBA is that they are system focused and design according to that. All requests from developers appear to be quirky and optimized from their "self-ish" point of view. By taking a system viewpoint we can standardize and optimize better. In the long run developers will appreciate a more stable and easier-to-learn system.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply