November 23, 2011 at 9:14 am
JP Dakota (11/23/2011)
Just happened yesterday, if you're wondering. A DBA added a column in the middle of the existing columns in a critical table. No kidding.
Generally I agree with your points, however, although I'm not a fan of unilateral changes adding a column in with other columns doesn't seem like such a crime since good coding practices will generally not cause a failure because of this new field..
So is it the addition that aggravates you or that it broke something?
CEWII
November 23, 2011 at 9:27 am
JP Dakota (11/23/2011)
Just happened yesterday, if you're wondering. A DBA added a column in the middle of the existing columns in a critical table. No kidding.Other than that I'm exacting, but generally easy to work with.
Was it me? There's a reason I consider SELECT * to be the enemy and as long as our sourcing tool reflects the changes you should have been good to go. I'm sure as heck not going to report to the entire team every time I make a minor schema change, like including a new column.
EDIT: Heh, guess I'm not easy to work with! 😉
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
November 23, 2011 at 9:37 am
peter.row (11/23/2011)
However what you said is totally one sided. You seem to be saying that the business people can get away without explaining to you or helping you understand what they want (even when you ask) and that it should be acceptable that they have no responsibility to aid the project you just have to lump it and accept their complaints.
I would disagree with that being what was said here, at least by Andy. I brought the business as a primary point into the discussion, Andy was mostly about the tech side of the team. A good portion of that is because I try to keep the business in the team, to avoid that exact scenario.
Most of the time in my experience when you have scenarios like that it's because IT has become the black box. When the team does the equivalent of locking the door to the cubes and finds that a meeting with the business people the equivalent of an hour of water torture, it comes across and they can't be bothered either, they're busy too. Get and keep them involved, and you'd be amazed at how rarely that occurs.
You have to have buy in on that from the general atmosphere of the company, but it does work well.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
November 23, 2011 at 10:16 am
When the team does the equivalent of locking the door to the cubes and finds that a meeting with the business people the equivalent of an hour of water torture, it comes across and they can't be bothered either, they're busy too. Get and keep them involved, and you'd be amazed at how rarely that occurs.
I find the common perception is that IT causes this, as noted here with your "lock the cubes" analogy. Certainly the classic half-door gateway to the old mainframe shop is a symbol of that. In my experience of being hard to work with, I have found that if I ask the business to be involved it is perceived as if I am asking them to do work for me or making excuses for not just coming up with the solution. Ask them to participate in testing, that sounds like I should have tested better, ask them for more detailed definition, I should know those answers, ask them to consider the financial consequences of asking for more bandwidth, forget about it.
November 23, 2011 at 10:28 am
WolforthJ (11/23/2011)
When the team does the equivalent of locking the door to the cubes and finds that a meeting with the business people the equivalent of an hour of water torture, it comes across and they can't be bothered either, they're busy too. Get and keep them involved, and you'd be amazed at how rarely that occurs.
......In my experience of being hard to work with, I have found that if I ask the business to be involved it is perceived as if I am asking them to do work for me or making excuses for not just coming up with the solution. Ask them to participate in testing, that sounds like I should have tested better, ask them for more detailed definition, I should know those answers, ask them to consider the financial consequences of asking for more bandwidth, forget about it....
Really? That has never been my experience.
At the beginning of any project, I approach the stakeholders and warn them I'll be regularly trying to pick their brains so I can properly understand their needs. Without exception, they've been gratified at being both consulted and involved, even if it costs them extra effort. This point is driven further home by the number of these stakeholders who then come back to me again after the project is finished and present me with a new challenge. I make sure they're involved, they then view me as a problem solver and seek me out again. It's a clear, strong, demonstrable and measurable link.
Semper in excretia, suus solum profundum variat
November 23, 2011 at 11:16 am
I approach the stakeholders and warn them I'll be regularly trying to pick their brains so I can properly understand their needs.
It has been about half and half for me. I try to find those reasonable people, usually the ones who do the work or are in the lower management tiers, and I have built good relationships with them and help to build my reputation. Eventually I run into higher management that doesn't understand how IT works and middle managers who are more interested in their territory than getting the job done.
I've never stayed at one job for over 5 years.
November 23, 2011 at 11:37 am
Elliott Whitlow (11/22/2011)
Depends on the topic.. If you want to do something monumentally boneheaded in SQL then I'm going with No, VERY difficult..CEWII
I probably am in the same boat. I try not to be - but it is verrrrrrry hard!
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 23, 2011 at 12:27 pm
SQLRNNR (11/23/2011)
Elliott Whitlow (11/22/2011)
Depends on the topic.. If you want to do something monumentally boneheaded in SQL then I'm going with No, VERY difficult..I probably am in the same boat. I try not to be - but it is verrrrrrry hard!
Where I'm really coming from is that locally I'm considered the expert and I try to offer suggestions in general, I'd rather not dictate where I don't need to. I try and trust my developers to do the right thing. In the past when someone was hell bent on going down a bad or really bad path I would squelch it, but even if I didn't agree with the path they were going that didn't generally mean they couldn't do it. I just put my foot down on a few things and in other cases a small change could get it back into line..
I've worked in small to ginormous organizations and without exception I've seen shody business requirements in all of them. The ones who say "here do it" are the worst because they don't understand how it actually works. The ones I've seen be successful are the ones where the development group gets the requirements, disects them and then asks for clarifications or gives pushback. In many cases a couple sentences which appeared to mean very little to the business accounted for hundred of hours of work without them knowing what they meant. And when informed they either took them out or told us what they REALLY wanted. I worked for a company that then wrote functional specifications, basically, this is how we read your requirements and this is how we plan to implement them. These were signed off by the business, this removed in most cases the ability to say, thats not what we wanted, because they signed off saying it was.. Then we built a technical specs document that laid out exactly how we were going to code it, how many sprocs, how many tables, how it would work at the base level. This document was available to the business analyst but he was not allowed to challenge it, technology used was the purvey of the development group.
CEWII
November 23, 2011 at 1:26 pm
SQLRNNR (11/23/2011)
Elliott Whitlow (11/22/2011)
Depends on the topic.. If you want to do something monumentally boneheaded in SQL then I'm going with No, VERY difficult..CEWII
I probably am in the same boat. I try not to be - but it is verrrrrrry hard!
May I apply for membership?
Non-sense is something that really pushes my buttons, the wrong ones.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.November 23, 2011 at 2:40 pm
WolforthJ (11/23/2011)
When the team does the equivalent of locking the door to the cubes and finds that a meeting with the business people the equivalent of an hour of water torture, it comes across and they can't be bothered either, they're busy too. Get and keep them involved, and you'd be amazed at how rarely that occurs.
I find the common perception is that IT causes this, as noted here with your "lock the cubes" analogy. Certainly the classic half-door gateway to the old mainframe shop is a symbol of that. In my experience of being hard to work with, I have found that if I ask the business to be involved it is perceived as if I am asking them to do work for me or making excuses for not just coming up with the solution. Ask them to participate in testing, that sounds like I should have tested better, ask them for more detailed definition, I should know those answers, ask them to consider the financial consequences of asking for more bandwidth, forget about it.
I've found phrasing to be as important as the involvement there. An example: Hey, can you make sure this works? is going to be taken wrong. "Hey, I've done the data level and interface testing that I can, can you take it through its paces for an average work day for you and make sure it's doing what you expect?" to be a lot more acceptable to the business.
I can't just come up with a solution, nor do I know the ins and outs of their jobs, and I explain that to them. "My specialty is technology, yours is 'x'. I can't do your job, but we can meet in the middle. Can you explain to me how you would approach this process?" If they're used to a 'snooty' IT department I could see how that could happen.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
November 23, 2011 at 5:01 pm
"Sometimes it takes someone who plays Devil's Advocate, who challenges, who dictates, who is single-minded, whose convictions are unshakeable".
I am glad you used the word "sometimes". I know a person difficult to work with. Communication is a two way negotiated process - it is a mediocre and cold manager who does not understand this and misses out on human-to-human interaction.
The manager who only "dictates" from afar, delivers communication only via electronic means and is too aloof and standoffish to speak directly is what I call the "snuffleupagus" manager and quite frankly a smart computer chip could do a similar job.
I once told this to a prior manager...it sent vibrations right up the management hierarchy and low and behold I soon was made to look like Big Bird - all fluff and no knickers.
November 23, 2011 at 7:53 pm
They’ve learned that the perfect is the enemy of the good, that some projects require inelegant solutions,...
While I agree that some projects don't require rocket science and the added scope that goes with it, I've found that a lot of people use that notion to take short cuts that just shouldn't be taken. The first things to suffer are embedded documentation, readability, and any chance for code to actually be scalable. That's provided that the code actually works according to the requirements.
I agree that "perfect is the enemy of the good" but I've found that there are a whole lot of people who don't know what "good" actually means. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2011 at 2:39 am
Elliott Whitlow (11/23/2011)
I've worked in small to ginormous organizations and without exception I've seen shody business requirements in all of them. The ones who say "here do it" are the worst because they don't understand how it actually works. The ones I've seen be successful are the ones where the development group gets the requirements, disects them and then asks for clarifications or gives pushback. In many cases a couple sentences which appeared to mean very little to the business accounted for hundred of hours of work without them knowing what they meant. And when informed they either took them out or told us what they REALLY wanted. I worked for a company that then wrote functional specifications, basically, this is how we read your requirements and this is how we plan to implement them. These were signed off by the business, this removed in most cases the ability to say, thats not what we wanted, because they signed off saying it was.. Then we built a technical specs document that laid out exactly how we were going to code it, how many sprocs, how many tables, how it would work at the base level. This document was available to the business analyst but he was not allowed to challenge it, technology used was the purvey of the development group.
I've been there and worked like that - it never really helped enormously and often worked out (possibly counter-intuitively) relatively unprofitably. We tended to find that the documentation would not be properly digested and understood. When the client received the goods they would be all like 'Where's this bit?' or 'How are you accounting for this?'. Totally unreasonable of course but they are the ones fronting the cash and at the end of the day it's pointless if you don't give them what is required. So we ended up quoting for the amendments, going through the process again, blah blah. Now we assume a level of change and try and be a bit more agile - not in a formal process way - I've found decent project management is better than trying to nail everything down. Of course if your clients are experienced in commisioning software or you are a very large corporate this may not be the case.
November 24, 2011 at 2:54 am
Mork (11/23/2011)
"Sometimes it takes someone who plays Devil's Advocate, who challenges, who dictates, who is single-minded, whose convictions are unshakeable".I am glad you used the word "sometimes". I know a person difficult to work with. Communication is a two way negotiated process - it is a mediocre and cold manager who does not understand this and misses out on human-to-human interaction.
The manager who only "dictates" from afar, delivers communication only via electronic means and is too aloof and standoffish to speak directly is what I call the "snuffleupagus" manager and quite frankly a smart computer chip could do a similar job.
I once told this to a prior manager...it sent vibrations right up the management hierarchy and low and behold I soon was made to look like Big Bird - all fluff and no knickers.
Absolutely. My style happens to be very much one of interaction, discussion and consensus, so the dictatorial character I laid out is one I personally find very difficult to work with. However, whilst I feel that attitude is rarely appropriate in the teams I've worked with, I can't deny I've seen those sorts of characters get results I would have been unable to achieve. I also realise there are very effective teams whose dynamics I would find absolutely abhorrent.
Semper in excretia, suus solum profundum variat
November 25, 2011 at 1:26 pm
Being easy to work with doesn't mean you can't be the one fighting for a better solution, or challenging an idea in progress. Being easy to work with means you can do it in a way that people understand why and how the conversation is needed. It doesn't mean you will never take an unpopular stance either, sometimes that is necessary.
For me it falls into the category of I know it when I see it. Vague but true!
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply