March 8, 2014 at 2:21 pm
I have often found myself in the past facilitating groups of less experienced individuals in building data warehouses.
One thing I have found the most challenging was trying to convince some of those involved that the way they wanted to do things was not the best way. For example ignoring some of Kimball's basic guidelines such as snowflaking when it's not necessarily required, making everything type 2 scds as no one wants to spend time doing the analysis or doing it this way 'because that's the way we've always done it'
Unfortunately the people offering up these things are the ones who have been at the company the longest and have the loudest voice!
Sometimes though it is difficult to find a specific reason why you shouldn't do something one way over another. Often these are the fundamentals seasoned dw developers take for granted and are never brought into question.
Have you guys had similar experiences? And if so what have you found is the best strategy to adopt in these scenarios?
March 9, 2014 at 11:26 am
The only way to influence those that can be influenced is to be right and to be able to prove it without question. As the old saying goes, 1 test is worth more than a 1,000 "expert" opinions.
The only way to influence those that can't or won't be influenced is to give them the opportunity to fail and be patient. Notice I did NOT say "set them up for failure". That could hurt the company and your reputation. If what they're doing is truly a bad idea, they'll fail on their own. Be prepared to pick up the pieces. I've actually worked jobs in parallel so that when someone fails, I have fully tested code ready to rock at the drop of a hat. I don't do that to make myself look good, either. I do it as a concerned employee that earns his pay and has the welfare of the company at heart. Sometimes it takes more work than it should but it does have its future rewards. The manner in which you tell them "I told ya" will weigh heavily the next time you try to influence someone. The best method is to not say anything like that. If they don't already know, then you telling them isn't going to help.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2014 at 2:24 am
Very interesting response Jeff. I guess a lot of people on here would echo your comments.....and like to have someone who you describe working in their team!
I guess the key thing is to not get frustrated when you feel people are going down the wrong path no matter how hard you try. As you say the trick is let them go and make their mistake and be ready to help out when it does all come crashing down!
March 10, 2014 at 2:50 am
aaa121 (3/10/2014)
Very interesting response Jeff. I guess a lot of people on here would echo your comments.....and like to have someone who you describe working in their team!I guess the key thing is to not get frustrated when you feel people are going down the wrong path no matter how hard you try. As you say the trick is let them go and make their mistake and be ready to help out when it does all come crashing down!
The problem though might be that the system might not crash and burn, but that it performs on a sub-optimal level.
You mentioned a lot of SCD2s (most authors do encourage that though, since SCD1 throws away all history) and snowflaking.
The result might just be that querying becomes more complex and slower, but it still runs. Maintenance will also be tougher. It will be hard to prove that you have an alternative design that is easier to query (ok that is easy to prove), but that is also faster and easier to maintain.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
March 10, 2014 at 2:57 am
@Koen yes, they were just a couple of many examples.
The difficulty comes when you are attempting to prove in the design stages that their proposed solution will be more difficult to maintain, overly complicated, harder to work on and take longer to add new functionality. A lot of those things are not as easy to quantify and are subjective.
Most of the people who have been challenging in this way do not see the benefits of designing something in the way I suggest as they have no had the experience on working a similar solution.
Without actually building and working on those solutions these issues will never be realised.
March 11, 2014 at 6:03 am
I've learned to follow four simple rules in my IT career:
1. Be honest.
2. Be direct.
3. Be polite/professional.
4. Don't take it personally if your ideas are vetoed/changed.
Practice these and you'll earn the credibility to influence others when it hits the fan and you're asked how to correct it.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply