November 22, 2014 at 12:44 am
Comments posted to this topic are about the item What Counts for a DBA: Empathy
November 22, 2014 at 1:33 am
From the article:
So, the next time a manager is screaming at you about deadlines, remember that it's probably not because of a lack of empathy or a desire to compromise on quality. It's because they are trusting you to understand the definition of "good enough".
No they're not. There's no trust in anyone understanding the "good enough" principle if they're screaming whether it's at the DBA, the architects, the Developers, or whatever. They're screaming because the deadline is looming and their butt is on the line and that's all. It's usually the sign of a grossly incompetent manager that never had a proper plan and certainly never had any proper control over the project or communication with the people on the project.
To be honest, I find this article to be one of the most condescending-towards-DBAs, Developers, etc, articles that I've ever read.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2014 at 6:33 am
Jeff Moden (11/22/2014)
To be honest, I find this article to be one of the most condescending-towards-DBAs, Developers, etc, articles that I've ever read.
I am sorry you feel this way. I am also not quite sure I understand. I am a DBA, Developer, and if I am being condescending to anyone, it would be managers. By and large, I feel like DBAs and Developers (particularly any of the data variety since that is the target audience!) are generally pretty amazing. I also believe that by and large, anyone who would spend time reading articles about how to be a better DBA is probably likely to be very good at what they do, or wants to be good at what they do.
Basically I am saying that sometimes you just have to realize that the manager is stressed out, and you have to play nice and understand what they may be going through, no matter if they are generally great or well the opposite of great.
I used first person a lot because I was noting my own personal tendencies towards quality at all costs, and I know that attitude occasionally rubs managers the wrong way. Sometimes it gets me a talking to 🙂
Jeff Moden (11/22/2014)
They're screaming because the deadline is looming and their butt is on the line and that's all.
Of course that's true. And they are filled with stress and are trying to get you to do what they need you to do, even if it isn't what you want to do. Often it is because the deadlines and/or the requirements have changed due to outside forces. And the word "screaming" is a bit of an exaggeration for effect. Usually it is sans any actual voice raising...
Jeff Moden (11/22/2014)
It's usually the sign of a grossly incompetent manager that never had a proper plan and certainly never had any proper control over the project or communication with the people on the project.
Note the use of the word usually. It means not all of the time. Sometimes it is because of outside forces. A few times in my life it was because I pushed back really hard on quality.. Maybe more than a few times.
The whole point of this is in the title. Being empathetic to the plight of the manager by knowing what they are going through. You go through much the same things at times, and you are both (generally) on the same team. Does it hurt to put yourself in their shoes?
However, this doesn't mean that all managers are great and are just a little bit stressed when they are mean. Some of them are just mean, incompetent, out of control, and have no right to be in control of other human beings. I have had a few of these... I have had more solid managers with good (if unexercised) technical skills who just have a deadline looming and occasionally have to make tough decisions to make quality decisions based on the "time, quality, cost" decision ... We can't take more time, we have no more money, so quality is what suffers.
November 22, 2014 at 12:14 pm
Perhaps it's because I've been shot at and missed, s--t at and hit so many times by front-enders and managers with their hair on fire in the face of a schedule that no one could actually hope to meet with any quality or scalability considerations or perhaps it's just the way you said things, but I didn't get any of that out of your article. It seemed to me to be yet another article chastising the people who are actually concerned with what the customer actually received for the sake of meeting some bloody schedule most likely agreed to by two suits in an elevator rather than with any thought as to what it would actually take. It also seemed to skip the most important part about how it should never get to your final point because there should be proper communication during the entire project.
That, notwithstanding and considering your explanation above, I apologize for taking your article the wrong way but do understand that, IMHO, it had all the earmarks of yet another telling of DBAs, Developers, etc, in a rather one sided fashion, to be empathetic at their own expense or the expense of the appearances of the company to managers that fail to be good managers.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2014 at 12:59 pm
Jeff Moden (11/22/2014)
It seemed to me to be yet another article chastising the people who are actually concerned with what the customer actually received for the sake of meeting some bloody schedule most likely agreed to by two suits in an elevator rather than with any thought as to what it would actually take.
Wow, I really hope not, and if many other people feel that way, I will rewrite it completely. Part of it is that in this series of blogs/articles, we shoot for a single point. In this case, just that single point that many times, managers are just a screwed in this process as we are and it wouldn't hurt for us to realize that they have managers, and their managers have managers, etc.
Actually, I am usually the one that gets in trouble in my writing/speaking for being too idealistic. In my database design book, I spent several chapters reminding people that they need to do requirements and figure out what the customer wants first. My db design precon spends good time on it too (which at least 1/30th of the attendees finds usually finds boring, based on the comments 🙂
The fact is, those two suits often make the decisions and timelines, and the rest of the storm falls on the technologists to solve their problem. If you work in a customer facing industry, someone makes an announcement of a new feature, and there is little that can be done. I hope too that I don't seem to imply that you should just let it happen either. Just that you are a team member, and every team member is probably suffering the same torments. So you do your best, make sure that your slice of the action is truly good enough and progress to the next task. (and if you can't get it good enough and feel completely devalued in the process as a rule, there are a few other places on earth to get a job as a dba!)
November 22, 2014 at 1:09 pm
Louis Davidson (@drsql) (11/22/2014)
Jeff Moden (11/22/2014)
It seemed to me to be yet another article chastising the people who are actually concerned with what the customer actually received for the sake of meeting some bloody schedule most likely agreed to by two suits in an elevator rather than with any thought as to what it would actually take.Wow, I really hope not, and if many other people feel that way, I will rewrite it completely. ...
I didn't take it that way at all. I thought you made a good point.
I've seen both scenarios:
- The manager who has no idea what it takes to get things done and sets deadlines arbitrarily.
- IT people who have no idea what it takes to make the business run and want things so perfect that they never get done.
We both need to understand each other a bit better.
November 22, 2014 at 3:32 pm
Louis Davidson (@drsql) (11/22/2014)
Jeff Moden (11/22/2014)
It seemed to me to be yet another article chastising the people who are actually concerned with what the customer actually received for the sake of meeting some bloody schedule most likely agreed to by two suits in an elevator rather than with any thought as to what it would actually take.Wow, I really hope not, and if many other people feel that way, I will rewrite it completely. Part of it is that in this series of blogs/articles, we shoot for a single point. In this case, just that single point that many times, managers are just a screwed in this process as we are and it wouldn't hurt for us to realize that they have managers, and their managers have managers, etc.
Actually, I am usually the one that gets in trouble in my writing/speaking for being too idealistic. In my database design book, I spent several chapters reminding people that they need to do requirements and figure out what the customer wants first. My db design precon spends good time on it too (which at least 1/30th of the attendees finds usually finds boring, based on the comments 🙂
The fact is, those two suits often make the decisions and timelines, and the rest of the storm falls on the technologists to solve their problem. If you work in a customer facing industry, someone makes an announcement of a new feature, and there is little that can be done. I hope too that I don't seem to imply that you should just let it happen either. Just that you are a team member, and every team member is probably suffering the same torments. So you do your best, make sure that your slice of the action is truly good enough and progress to the next task. (and if you can't get it good enough and feel completely devalued in the process as a rule, there are a few other places on earth to get a job as a dba!)
Heh... you're doing it again. 😉 Perhaps I'm missing the physics here. Or, maybe we're talking about the same thing and don't know it. Saying things like "Just that you are a team member, and every team member is probably suffering the same torments" and "so do your best" and "feel completely devalued" and "other places... to get a job" sounds more like a lecture on how workers need to behave rather than how to revel and excel all while helping the TEAM to excel and the company to meet its goals without getting a black eye in the view of the customer whether by not meeting a schedule or by not meeting quality, performance, or safety expectations or all the above.
Now, if what you really mean to say (and I believe you do) is that DBAs are normally the more senior members (average age is 44 according to many websites) of a team with a whole lot of experience under their belt and they can provide real value, especially in the face of "impossible" (notice the quotes) schedules by showing their TEAM members shortcuts that won't shortcut quality, safety, or performance of code, educate them as to why certain shortcuts shouldn't be taken and how it could bring a world of hurt to the company if they do, and having the knowledge and skill to identify those things that are important and those that are not, as well as rolling up the ol' shirt sleeves and digging in to help, then I'm with you! Yes, you need to be empathetic towards the manager (sometimes, even if they don't deserve it because you're thinking of the Team and the company that makes their employment possible) but it's the Team that needs the real empathy and a good DBA or group of DBAs can really make the difference!
And, to be honest, the DBAs should be mentoring everyone with this type of knowledge long before any crunch is perceived so that when there is a crunch, the TEAM works surely and flawlessly towards the end goal. Just like any sports team that's bound to win, there need to be drills, practice, rehearsed moves for multiple situations, and lots of helpful instruction/training. As David Poole once said, "If you are in the position where people will voluntarily use you as the first point of contact for database information rather than the last then you are probably an exceptional DBA" not to mention being the empathetic individual that your article tried to encourage.
Heh... you can't fight a fire with empathy. You need to train someone how to hook up the hose and turn on the water. DBAs and Lead Developers can and should do that and that's going to take some "empathy" and "dedication". 😛
If that's what you really meant, then I'm in complete agreement. :w00t:
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2014 at 3:36 pm
marcia.j.wilson (11/22/2014)
Louis Davidson (@drsql) (11/22/2014)
Jeff Moden (11/22/2014)
It seemed to me to be yet another article chastising the people who are actually concerned with what the customer actually received for the sake of meeting some bloody schedule most likely agreed to by two suits in an elevator rather than with any thought as to what it would actually take.Wow, I really hope not, and if many other people feel that way, I will rewrite it completely. ...
I didn't take it that way at all. I thought you made a good point.
I've seen both scenarios:
- The manager who has no idea what it takes to get things done and sets deadlines arbitrarily.
- IT people who have no idea what it takes to make the business run and want things so perfect that they never get done.
We both need to understand each other a bit better.
I absolutely agree on the "understanding each other a bit better" thing but it presumes that the good people in IT, especially DBAs, want things to be "perfect" with no understanding of anything else on their part. My exception to this article is that nothing could be further from the truth and, despite the extremely noble intent of the author, it shines a bad light on good DBAs that actually know what being a DBA means.
Of course, that's just my opinion.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2014 at 3:48 am
I have to totally disagree with the following from the article:
Database development has a subtle difference from application-development. It is not as easy to fake your completion dates, i.e. using technical debt (a.k.a. dirty hacks) to meet a deadline and then quietly filling in the gaps later. In a database, this is a sure route to invalid data, missed orders and unhappy customers.
Technical debt in application code is usually permanent. Or at the very least long term. In my experience more systems with databases have DBAs that are allowed to alter the database along the way than application support developers who are allowed to change a single line of code which isn't related to a specific defect. There is no "quietly filling in the gaps later".
Also there are temporary shortcuts that could be done in a database that can be backfilled by production DBAs without adversely affecting data. A particular example I have seen is the delayed delivery of a datawarehouse database with reports temporarily (inefficiently) produced from a duplicate (often restored backup) read only version of the production database.
As for empathy with PMs, it is good to have it but it must be tempered when they say that a "deadline has been forced on them" as it is their responsibility to highlight when such deadlines are not achievable whilst maintaining a satisfactory level of quality.
I must say that I lean towards Jeff's point of view although I totally agree with Marcia too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 24, 2014 at 5:39 am
I've seen managers say they've had deadlines imposed on them when they've really just decided in their own minds how long something should take and then scream up the food chain, thinking this will somehow get things done faster. Some promise things to the client without considering how long it'll actually take and then expect the DBAs and developers make up the difference. Neither is a sign of a good manager.
Regarding the "technical debt" and "without the interface being on time" comments, I would rather deliver nothing at all than deliver something that's wrong. Perhaps this point is the a good place to start when trying to "understand each other better" for me. I have no tolerance for publishing production data that isn't right.
November 24, 2014 at 6:10 am
It seems to me that it depends on relationships. If you as a developer/dba/programmer/coder/whatever have enjoyed a trustworthy relationship with your manager because you have given your 110 percent in the past and gotten the job done, then your manager knows your capabilities and will give you reasonable deadlines with the expectation that you will be able to meet them. So, if you encounter issues with the project that could impact your deadline, you could then approach your manager and tell them you've encountered a problem and your deadline needs to be adjusted. Your manager then should be able to approach the higher-ups and advise them about the changed deadline. This assumes all players have credibility with their superiors. Of course nothing beats a collaborative approach, where the developer/dba/... contributes opinions regarding tasks and deadlines that are considered during project definition.
Also, there is a triumvirate of price, quality and speed. You can generally get 2 of these, but not all three. In other words, you can get good and fast, but it won't be cheap. Or you can get fast and cheap, but it won't be good. This generally applies to construction and I think it fits our business as well. There are always exceptions (ie a quick and dirty report that the end user loves).
November 24, 2014 at 6:42 am
alicesql (11/24/2014)
...Also, there is a triumvirate of price, quality and speed. You can generally get 2 of these, but not all three. In other words, you can get good and fast, but it won't be cheap. Or you can get fast and cheap, but it won't be good. This generally applies to construction and I think it fits our business as well. There are always exceptions (ie a quick and dirty report that the end user loves).
I have been thinking about this famous triangle for some time and the term "cheap" and even "price" has not sat well with me. I think that the reason is that, almost inevitably, cost comes back to haunt us. Maybe the triumvirate is partially deferred cost, quality and speed???
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 24, 2014 at 7:29 am
Gary Varga (11/24/2014)
alicesql (11/24/2014)
...Also, there is a triumvirate of price, quality and speed. You can generally get 2 of these, but not all three. In other words, you can get good and fast, but it won't be cheap. Or you can get fast and cheap, but it won't be good. This generally applies to construction and I think it fits our business as well. There are always exceptions (ie a quick and dirty report that the end user loves).I have been thinking about this famous triangle for some time and the term "cheap" and even "price" has not sat well with me. I think that the reason is that, almost inevitably, cost comes back to haunt us. Maybe the triumvirate is partially deferred cost, quality and speed???
This conversation has been argued many times on this site but I very much agree with what Tom Tompson said on one of them. If you always go for Quality, there's a really good chance that Speed and Price will fall inline, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2014 at 8:16 am
Jeff Moden (11/24/2014)
Gary Varga (11/24/2014)
alicesql (11/24/2014)
...Also, there is a triumvirate of price, quality and speed. You can generally get 2 of these, but not all three. In other words, you can get good and fast, but it won't be cheap. Or you can get fast and cheap, but it won't be good. This generally applies to construction and I think it fits our business as well. There are always exceptions (ie a quick and dirty report that the end user loves).I have been thinking about this famous triangle for some time and the term "cheap" and even "price" has not sat well with me. I think that the reason is that, almost inevitably, cost comes back to haunt us. Maybe the triumvirate is partially deferred cost, quality and speed???
This conversation has been argued many times on this site but I very much agree with what Tom Tompson said on one of them. If you always go for Quality, there's a really good chance that Speed and Price will fall inline, as well.
Now that you mention it, I think that I too agreed with Tom's opinion on one of the reruns of that debate 😉
It is my opinion that this applies not only to SQL (which I think is what both you and Tom think anyway but have added here for clarity).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 24, 2014 at 7:43 pm
Gary Varga (11/24/2014)
I have to totally disagree with the following from the article:Database development has a subtle difference from application-development. It is not as easy to fake your completion dates, i.e. using technical debt (a.k.a. dirty hacks) to meet a deadline and then quietly filling in the gaps later. In a database, this is a sure route to invalid data, missed orders and unhappy customers.
Technical debt in application code is usually permanent. Or at the very least long term. In my experience more systems with databases have DBAs that are allowed to alter the database along the way than application support developers who are allowed to change a single line of code which isn't related to a specific defect. There is no "quietly filling in the gaps later".
Fair enough. Though I have seen far more applications that have been rebuilt using newer technologies multiple times with the same base database structures. Things are tough all over, and yes, complex processes do end up in the same trouble where everyone is afraid to change touch the code... But if you can't change the code, you probably can't do too much to the database either...
As for empathy with PMs, it is good to have it but it must be tempered when they say that a "deadline has been forced on them" as it is their responsibility to highlight when such deadlines are not achievable whilst maintaining a satisfactory level of quality
Look, I am going to say this a few more times, but I wasn't trying to cover everything, just one tiny aspect of the process. More or less "Do unto others as you would have them do unto you".
Part of the issue is that this is just one article in a series over on Simple-Talk (https://www.simple-talk.com/blogs/author/2155-louis-davidson/) and was not meant as a complete primer on being a DBA, or even in the manner of dealing with management situations. Only that hatred that we all have for managers (yeah, me too...Gets me in trouble with my wonderful manager quite often!) that ought to be tempered with a bit of realizing that they have a job to do too.
No matter if they are smart as a whip or are dumb as a post when it comes to what we do, they have a job to do that is not any easier than ours. They get stuff shoved on their plate, unrealistic requirements, etc etc and they have as much chance of getting the quality point across as we do. I have never met a person who worked for the perfect organization where you could always push back even using excellent logic. It is just not always possible.
I must say that I lean towards Jeff's point of view although I totally agree with Marcia too.
I don't think I can make it any more clear that to say "me too". And I possibly should have changed this last sentence:
"It's because they are trusting you to understand the definition of 'good enough'. "
to say
"It's hopefully because they are trusting you to understand the definition of 'good enough'. "
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply