Friday, September 23, 2005
What Separates DBAs from Developers--Part II
21:25 | 
Posted by
Sean McCown
I don't know if any of you remember last week's post where I talked about some of the bad code I've seen, and the reasons why many developers don't seem to ever learn their lessons. Well, the most amazing thing has happened that may just explain the whole mystery.
I was looking through my wife's copy of Redbook this week and ran across an article about autism. To make a long story short, the article states that autistic people quite often go into programming careers. That really explains a lot doesn't it? As it turns out, programmers are genetically predisposed to buying their underwear at K-Mart. OK-OK, I'm just giving you guys a hard time. I'm just kidding... but Redbook really did say that autistic people tend to go into programming. If you don't believe me check it out. It's in the Sept 2005 issue on pg 197.
Ok, onto some serious business. I wasn't going to write on this topic again, but there was such an overwhelming response last week, I thought some of you needed more time to get it out of your system. And while some of you had some good arguments, others of you went so far as to insult me personally, while still others of you left me with some really interesting grammar lessons. I really don't mind the insults though. I kind of expect it actually after a posting like that.
Now, I think some of you are confusing a rant blog for real life. Just because I come on here and rant about something doesn't mean that I don't have a teamwork attitude at work. In fact, I'm always the first one to turn on People's Court(yeah, yeah, time for Wapner) when our developers need help. I teach SQL classes to show them the right ways to write code, and even give them DOs and DON'Ts. It never makes any difference though. When they turn their code in it always looks the exact same way it did before. Go figure. But of course you have to have a teamwork attitude with everyone. How else would you ever get your job done?
One of you said that it was a training issue. This is quite true. Training is the key. The problem is in getting them to get the training. You can make them sit in a classroom but you can't make them care. And that doesn't mean that I think all devs are bad either. There are exceptions, and I've even met a couple.
I really don't expect everyone to know everything, or even most of everything. And I certainly don't know everything, nor do I claim to. I'm sure that the answers I give to a complicated problem are not only different from what someone like Kalen Delaney or Kim Tripp would give, they're different from the answers I'll be giving 5yrs from now. Just as they're different from the answers I gave 5yrs ago. The good news is that the SQL superstars go through the same thing. Their answers changed based off of their current level of experience.
What I do expect though is for some of the basics to rub off after a certain amount of time. I expect that devs would know not to hardcode index hints, or put a clustered index on description varchar(200). I would also expect that you wouldn't put extra indexes to speed up inserts, or put 4 indexes on a 2 column table. Yet these are all things I've seen numerous times.
Maybe we should all swallow our pride and concentrate more on getting the job done and less on pointing fingers. I think I have a solution though. Why not base a bonus structure on the quality of the code when it hits production? So, you've got a 3 month window. You start out with $500 as a bonus whenever you push a major release into production. Then, for every problem caused by something you coded, you lose a portion of your $500. So, the DBAs have to fix a horrible query, you lose $100. They have to take out an index hint, $50, etc. Now answer me honestly... how many developers do you think would learn to think in sets then? How many times do you think our advice would go ignored? How many of the lazy 'select *' queries do you think we'd see? Anyway, just a thought.
And the same goes for DBAs too. How about the same type of structure for the systems. How many times do you want to lose your bonus because you didn't back up a DB properly, or didn't test the restore? How much money do you want to lose because you did something stupid and brought the system down, or left the where clause off of a delete and killed the whole table?
The problem we have at my office is that the devs don't write good code, and the users have become to expect that SQL runs very slowly. A very good example comes from a conversation I had with one of the production managers last year. She called and said they were having trouble with the reports. They're taking a long time to come up. I said, ok, which report. She told me which one, and said that it was taking about 35mins to come up. I said, and how long does it usually take? She said... it usually comes up pretty fast. The normal time is about 25mins. After I fixed the immediate problem I looked into the queries themselves. Once I finished with them, they came up in less than a second. It's very easy for users to get used to DBs performing poorly. If it's never been a fast system they have nothing to compare it to. It's up to all of us to set their expectations. We had a problem last week with another bit of code in which they were complaining that it had gone from 4secs to over 2mins. One of my DBAs took the ticket, and told the customer that the performance was unacceptable. The customer said, yeah, I know, that's why I'm calling. It used to take 4secs. My DBA said, no I mean the 4secs is unacceptable. Let's get that time down.
OK, maybe next week I can finally talk about batch deletes like I promised last week. Until then, remember... K-Mart sucks.
One more thing...
Don't forget Rahul Sharma is a cheat and a fraud.
So nobody buy his book... ever, Ever, EVER!
His book is: Microsoft SQL Server™ 2000: A Guide to Enhancements and New Features
I was looking through my wife's copy of Redbook this week and ran across an article about autism. To make a long story short, the article states that autistic people quite often go into programming careers. That really explains a lot doesn't it? As it turns out, programmers are genetically predisposed to buying their underwear at K-Mart. OK-OK, I'm just giving you guys a hard time. I'm just kidding... but Redbook really did say that autistic people tend to go into programming. If you don't believe me check it out. It's in the Sept 2005 issue on pg 197.
Ok, onto some serious business. I wasn't going to write on this topic again, but there was such an overwhelming response last week, I thought some of you needed more time to get it out of your system. And while some of you had some good arguments, others of you went so far as to insult me personally, while still others of you left me with some really interesting grammar lessons. I really don't mind the insults though. I kind of expect it actually after a posting like that.
Now, I think some of you are confusing a rant blog for real life. Just because I come on here and rant about something doesn't mean that I don't have a teamwork attitude at work. In fact, I'm always the first one to turn on People's Court(yeah, yeah, time for Wapner) when our developers need help. I teach SQL classes to show them the right ways to write code, and even give them DOs and DON'Ts. It never makes any difference though. When they turn their code in it always looks the exact same way it did before. Go figure. But of course you have to have a teamwork attitude with everyone. How else would you ever get your job done?
One of you said that it was a training issue. This is quite true. Training is the key. The problem is in getting them to get the training. You can make them sit in a classroom but you can't make them care. And that doesn't mean that I think all devs are bad either. There are exceptions, and I've even met a couple.
I really don't expect everyone to know everything, or even most of everything. And I certainly don't know everything, nor do I claim to. I'm sure that the answers I give to a complicated problem are not only different from what someone like Kalen Delaney or Kim Tripp would give, they're different from the answers I'll be giving 5yrs from now. Just as they're different from the answers I gave 5yrs ago. The good news is that the SQL superstars go through the same thing. Their answers changed based off of their current level of experience.
What I do expect though is for some of the basics to rub off after a certain amount of time. I expect that devs would know not to hardcode index hints, or put a clustered index on description varchar(200). I would also expect that you wouldn't put extra indexes to speed up inserts, or put 4 indexes on a 2 column table. Yet these are all things I've seen numerous times.
Maybe we should all swallow our pride and concentrate more on getting the job done and less on pointing fingers. I think I have a solution though. Why not base a bonus structure on the quality of the code when it hits production? So, you've got a 3 month window. You start out with $500 as a bonus whenever you push a major release into production. Then, for every problem caused by something you coded, you lose a portion of your $500. So, the DBAs have to fix a horrible query, you lose $100. They have to take out an index hint, $50, etc. Now answer me honestly... how many developers do you think would learn to think in sets then? How many times do you think our advice would go ignored? How many of the lazy 'select *' queries do you think we'd see? Anyway, just a thought.
And the same goes for DBAs too. How about the same type of structure for the systems. How many times do you want to lose your bonus because you didn't back up a DB properly, or didn't test the restore? How much money do you want to lose because you did something stupid and brought the system down, or left the where clause off of a delete and killed the whole table?
The problem we have at my office is that the devs don't write good code, and the users have become to expect that SQL runs very slowly. A very good example comes from a conversation I had with one of the production managers last year. She called and said they were having trouble with the reports. They're taking a long time to come up. I said, ok, which report. She told me which one, and said that it was taking about 35mins to come up. I said, and how long does it usually take? She said... it usually comes up pretty fast. The normal time is about 25mins. After I fixed the immediate problem I looked into the queries themselves. Once I finished with them, they came up in less than a second. It's very easy for users to get used to DBs performing poorly. If it's never been a fast system they have nothing to compare it to. It's up to all of us to set their expectations. We had a problem last week with another bit of code in which they were complaining that it had gone from 4secs to over 2mins. One of my DBAs took the ticket, and told the customer that the performance was unacceptable. The customer said, yeah, I know, that's why I'm calling. It used to take 4secs. My DBA said, no I mean the 4secs is unacceptable. Let's get that time down.
OK, maybe next week I can finally talk about batch deletes like I promised last week. Until then, remember... K-Mart sucks.
One more thing...
Don't forget Rahul Sharma is a cheat and a fraud.
So nobody buy his book... ever, Ever, EVER!
His book is: Microsoft SQL Server™ 2000: A Guide to Enhancements and New Features
Subscribe to:
Post Comments (Atom)
About Me
- Sean McCown
- I am a Contributing Editor for InfoWorld Magazine, and a frequent contributor to SQLServerCentral.com as well as SSWUG.org. I live with my wife and 3 kids, and have practiced and taught Kenpo for 22yrs now.
Page Views
18 comments:
It is understanding that allows us DBAs to tolerate developers.
;)
Love your blog, always gives me a laugh.
Chuck
If this blog entry had any intention of trying to convince others that you are not an arrogant jerk, you failed miserably.
You would like us to believe that you can come off like an arrogant jerk in this blog, which is read by your peers (even though you may think you have no peers), and yet be a real sweetheart to work with as a fellow employee. BS! I would guess that you are seen as an arrogant jerk at work as well. Based on some of your comments in this blog, I suspect it does not even bother you.
I'd say anyone posting as anonymous isn't worth listening to anyway. Excellent blog, thanks
I think it's all about maintaining a 'humble' attitude - in a technical profession you are always learning, you don't know it all. Now we have the internet you can often find some great ideas on how to change your code or implement something new and there's no shame in it or there shouldn't be.
DBAs can be just as guilty of thinking they know it all, or pretending they do, people tend to link their ego and sense of self worth closely to their jobs so the whole areas a minefield. I knew a guy who'd 'been working with databases for 25 years - so don't tell me... etc' it was true but even in 25 years he hadn't seen everything, not by a long way and there's nothing wrong with that ... unless you don't realise it.
sorry about posting as anonymous -I'm not the one who posted before, honest ;-)
Very amusing!
I look forward to part 3 and beyond, as well as the humourless literal flamers who post as "Anonymous"
Following your latest DBA/Developer observation you have stimulated me to add my bit. I am primarily a developer and I am here at home trying to build a web application. So, I end up designing the database and it's stored procedures, building the business logic, understanding and writing HTML/CSS, coding for security (a mammoth task in itself) and so on and on and on. Meanwhile I've got to down tools and go off deliver stuff every now and then to earn some money to live. You see I am so old that noone would dream of employing me in the software industry.
It's a complex road but, like your other commentators, I would never dream of writing such rubbish SQL in a million years. I do however come across stuff I just have never heard of despite the enormous hours I have put in.
What is development like? Here's a real life scenario from yesterday. I have just read through the "Managing Users" chapter of "Hacking the Code" by Burnett and Foster when I come across Code Audit Fast Track/Avoid Easily Guessed Credentials/ Does the application avoid using sequential user account numbers? I stop in my tracks - they have already outlined an attack where someone got in enough to query on UserID using values like 1,2 .. 100, 1000 and so on. Oh dear. That means that using int and IDENTITY on a column is a bit risky. So, what now? I go to "Inside SQL Server 2000" by Delaney/Gray. I come across the type uniqueidentifier which is briefly explained in 2 pages with a comment "You can use the uniqueidentifier for whatever reason you come up with, ..." Aha! What if I used it as a primary key! I think I am having an original thought, I go to Google shove in the search words and guess what? the world has been doing it for ages.
The point of my story is that as a developer it sometimes feels like we are trying to map the world in a kayak and we are always going to round a bend and sometimes find we have little to go on to deal with a new situation. Now, is the local expert going to emerge from the forest and laugh at our untidy efforts. Of course as we are "good" explorers we hang around a bit and learn these new skills but soon we are off to other parts and new situations.
What have you to say? Well you said "To make a long story short, the article states that autistic people quite often go into programming careers. That really explains a lot doesn't it?".
Try substituting a few other words for autistic, like female, black or crippled. Doesn't much sound like an argument or a funny comment now does it?
As you might have guessed I have a son who is on the mild end of the autistic scale and it means life is quite lonely and difficult in many respects. He is however smart enough to get good exam results and is now studying geology. One report described him as 'gifted'. As his father I understand some of his problems because I have also found it difficult at times, although I am lucky not to have such strong traits. I found myself talented at programming and have earned a living most of my life ...
So please don't be so quick to fire these unpalatable comments around, after all, I could just say "Well, he comes from Texas. That really explains a lot doesn't it?"
Mike
Hey Ben Smith (you are still anonymous to me),
Who's more obnoxious in a society, one who overtly acts like an arrogrant jerk and simply does not care, or one who covertly tells an arrogant jerk he/she is acting like an arrogant jerk?
You people are missing the point completely. Who cares about relational databases and SQL. I long for the day when OO databases rule the earth. You SQL weenies will need some training then.
Nice insult!! how many DBA's do you know that can even code outside of script. Most coders, and just like everything else there are bad ones, can do most all of the dba's tasks. In fact there were coders long before DBA's and because of this many of us can do the DBA's job and in fact have mentored many DBA's.
Hi Sean,
Gr8 blog, loved the 4 sec bit.
I've only started SQL but got good training from a senior.
Kind of understand how u'd feel abt all the (anti) comments as I once said "Not everyone can write SQL" in a room full of developers...
May I request u to post the DOs and DONTs mentioned in ur article for reference please?
Thanx
Hi Sean,
Gr8 blog, loved the 4 sec bit.
I've only started SQL but got good training from a senior.
Kind of understand how u'd feel abt all the (anti) comments as I once said "Not everyone can write SQL" in a room full of developers...
May I request u to post the DOs and DONTs mentioned in ur article for reference please?
Thanx
What I insult!! How many DBA's understand business, can code anything outside of script, know how to write and talk. Lookslike your the perfect know it all DBA.
Like many coders, I have worked a long time before there were even DBA's, can do most of the DBA's job and have taught many DBA's how to do there tasks.
"I think some of you are confusing a rant blog for real life."
A blog IS real life. Do you have multiple personalities, one for your blog, one for your job, one for your _____? Maybe Redbook has an article about that condition.
I love DBA's I am certified myself, insane and Microsoft. I like to think of DBA's as up and coming developers, who need some emotional help coming out of the corner and closet for the most part. Nothing makes me happier than to have 8 or 10 inner joins in a query and tack a * onto the ass end of the select list. This inevitably causes a lot of giggles and laughing in the IT department.
As a developer all I can say is "I am sorry.." ohh... and collaboration is key.
The key is to have those with authority and guts to fire anyone in IT who is an impediment to getting the job done. And then be able to recognize talent (or solicit help from those who can recognize it) in the interviews. In my experience as a developer, I've seen more incompetent DBAs than I care to mention, and lost count of the number of times I had to tell them how to do their job, or give up and do it myself. I've also been tremendously frustrated with idiot developers, too, and have been soooo glad to see them let go. What you find, though, is that there are more developers than DBAs in shear numbers, which will give you more idiot developers than idiot DBAs. Percentage-wise, I'd bet the farm that the numbers are pretty close to the same.
You have very nice and useful source. Krosavcheg!
louis vuitton replica bags
advance cash loan loan paycheck payday
advance cash cash loan loan payday quick
bad credit loan personal quick
short term personal loan
advance advance cash loan loan paycheck payday
advance cash from loan online payday quick toda
payday loan lender
emergency fax loan no payday
24 hour payday loan
credit free online report score
Good Luck!
25mg celebrex RX floxin Pharmacy gyne-lotrimin RX elimite RX ponstel Canadian albenza
Post a Comment