Instead of working, I blog.

What do you do when someone at work is gunning for you?

I’ve started up a discussion on the IW forum.

I’d like you to take a look at it because this could be a huge topic.

http://www.infoworld.com/d/data-management/forums/gunning-you-747

 

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

I spent the week at TechED in L.A. and I had the (good?) fortune to sit in on a couple .Net sessions.  The most memorable of course, and the one that attracted me to begin with was on data access tricks.  I didn’t have a session guide with me at the time so I didn’t know it was a .Net session till I got there, but man, once i started listening i was amazed.

Ok, so the course was about data access tricks… and hearing .Net guys talk about SQL and DB access is like listening to your 5yr old explaining to your 3yr old why it rains.  It’s no wonder why there are so many poor apps out there when one of the big data access tricks is to create a view in the DB for large joins.  Now, I’m not saying that the guy suggested using a view instead of putting a large join query on the front end… no, not quite.  He was actually announcing it like it had just been created… the latest thing developed by the SQL world to get around an age old problem.  And I’ll tell you too… the ooos and aaaahs were plentiful.

Another good one was creating a view to get around all that pesky crap the DBAs make you do like solving many-to-many queries with lookup tables.  The way they were whining about that and saying what nonsense it was is incredible.  I thought about raising my hand and offering some constructive criticism on the matter, but I get enough of those conversations at home when I’m arguing with my kids about why they can’t have candy for dinner in the middle of the street.

Now, ordinarily I wouldn’t mind this kind of thing too much, but I think part of the problem with .Net devs being so puerile about these things is that their leaders aren’t guiding them.  Because instead of complaining about DBAs making them use lookup tables, which are necessary in many designs, he could have approached it from the professional angle of… hey you know how you have to solve a many-to-many with lookup tables and how much work that is on the front end?  Well here’s an idea, have your DBAs give you a view for that on the back end and you can just select from it in your C# code.  Now that makes .Net guys sound like professionals who know a thing or 2 about coding and about data access instead of whiney babies who are being made to go to bed early by the DBAs.

So I know I’ve said this before but it bears repeating because it keeps coming up… devs just don’t get it.  And seriously guys, if you really can’t see why your DBAs make you do the things you do, then you deserve this rant.

You take performance and concurrency pretty seriously in your apps, so why can’t you apply that to your data access as well?  So it’s time to grow up and become real adult IT folk.

Paul Tripp has asked that I urge all of you go on to his site and take his quick survey. It's really quick so it'll only take a minute.
And those of you who know Paul's work know he's probably doing it for a reason.

http://www.sqlskills.com/BLOGS/PAUL/post/Weekly-survey-does-size-really-matter-or-is-it-what-you-do-with-it.aspx

I have a friend whom I don't get too see hardly ever and he wrote me the othe day and said that he really enjoys my rants here... and he says I'm only half full of it most of the time.

I like that. I don't think I've ever been described as only half full of it.
So thanks man, you know who you are.

One of the biggest problems DBAs face when trying to cleanup an environment is fighting the user base. We're quite often forced to limit access they've grown used to and even to institute policies the limit what they can and can't do within their code.

Now, here I'm talking about SQL code mainly, but it also stretches to things like deploying new reports and the like.

I call this post the speed of stupidity because most of the problems that need to be cleaned up happen because users get an idea and before they even consider whether it's a good idea or not, or whether the way they thought of to do it is the way it should be done, or whether somebody's even already doing it, they bang out the code real quick and push it to the server... where it proceeds to do its particular brand of damage. And this is really the hardest thing to control in any company where people have had full reign to do whatever they want whenever they want. And it's really hard to explain to them and to demonstrate to them that they're doing more harm than good. And what's worse is that they typically have the FULL backing of upper management.

And management is where it gets tricky because quite often it's the directors and VPs who are pushing their people to produce this code right away. They honestly have lost their ability to reason the logistics of their business. They never even stop to think of performance on the server so it never crosses their mind that there may be a reason to wait. They're so concerned with the fact that they had what they consider to be a good idea and they're now tunnel-visioned on that goal. Not only that, but at this point they've actually convinced themselves that their business can't last another day without this code being in place. This is where that reasoning breakdown comes in. Do you honestly mean to tell me that your company has grown and made money and done solid business for 15yrs, but it's all going to crash down because you don't get this new report by noon? Do you really think this report is that important? Is it important enough to bring the other reports to a halt?

And that's at the heart of this post. It takes a while to architect a good report and get the code right and test it and tweak it, but you can be stupid in an instant. This is what DBAs have to fight. We have to find a way to convince upper management that they can push code into production just because it crossed their minds. They have to learn to slow things down and think them through. It's still ok to give their people assignments to write reports, and other SQL code, but they have to understand that there has to be a process to not only make sure that it's going to be done well, but also that it hasn't already been done by someone else.

And I'm telling you, that's a hard attitude to change. So the next question is, how do you go about changing that attitude? Well, it happens very slowly. You first have to determine the problem. Then you have to determine a fix. Then you have to gather stats from the server. And sometimes depending on the nature of the problem, you could need to gather the data for just a day or 2, or a couple months even.
If it's SQL code, you can code your fix and run the 2 blocks of code next to each other and log the performance differences. Then you can pull stats on how often that code gets run and show a definite improvement over a block of time. If that code is causing deadlocking, or blocking, or just other general contention you'll also want to log the amount of time you spend dealing with these issues. This is what can take a month or 2 because you'll need a large enough sample to be conclusive. Then when you've got the performance gains charted out, you can also list the time you spent dealing with the issues and present that to management. It's really hard to ignore the issue when the numbers are right in front of them. Managers respond really well to hard numbers and if you present them with the hard numbers that prove how much time you spend on issues that could have been avoided by following a process, then they're much more likely to listen. And there could be some other factors as well. These issues tend to stack up on each other and can effect SLAs and application uptime. So these are other factors that should be presented if they apply.

When you take these numbers to the manager you'll want to present it in a way that more helpful than offensive. You know he's the one who's been allowing this to go on, and he does to. So there's no need to rub his nose in it. Just present it as a way to solve a problem that's costing the company money. Look, here's all the time I've spent working on these issues in production that could have been avoided had there been a process to review the code beforehand. A manager would be a fool to ignore this level of proof that things need to change.

Look guys, I know having that new idea gets you excited and you want to see it materialized as soon as possible. But that doesn't mean it should be. Take a minute and think whether the company will really fold if your code isn't pushed into prod right away. What's the real business value to what you want to do? Will it really help you make decisions or help you do something you really need, or is it just nifty to be able to do? Don't waste time and resources on something that's just nifty to know. It has to actually provide something useful to your business.

OK, I'm bordering on rambling here but you get the idea. Let's slow down and start doing things right.