June 26, 2008 at 8:13 am
Jeff Moden (6/26/2008)
I think you're being very generous... I've found that about half the time it's because they're simply a crappo developer that can't program worth a hoot in any language... it's just that most languages cover up for the huge mistakes that they make... SQL doesn't. 😉
OK there are a lot of those and I blame the programming language vendors for adding so much automatic garbage collection to their processes which has opened it way up to extra garbage. :sick:
June 26, 2008 at 8:13 am
Jeff
Have you consider decaf?:w00t:
David
June 26, 2008 at 8:20 am
Antares686 (6/26/2008)
Jeff Moden (6/26/2008)
I think you're being very generous... I've found that about half the time it's because they're simply a crappo developer that can't program worth a hoot in any language... it's just that most languages cover up for the huge mistakes that they make... SQL doesn't. 😉OK there are a lot of those and I blame the programming language vendors for adding so much automatic garbage collection to their processes which has opened it way up to extra garbage. :sick:
Exactly... they don't even have to think anymore... and they don't. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2008 at 8:26 am
David O (6/26/2008)
JeffHave you consider decaf?:w00t:
David
Nah. It's just that time of the hour for him. 🙂
He does have a good point. I've worked with people who could build really good C#/Java/whatever code, who didn't know SQL all that well, but they knew they had a weakness in SQL, so they came to me for help on it on a regular basis. I've also worked with people who refused to ask for help, for various reasons, and who churned out junk procs on a daily basis. Those same people had the same attitude about their front-end code, and produced error-prone, slow, applications that nobody liked and that didn't provide essential functionality, which always took too long to build and were never finished. It's a pattern.
The same thing applies to pretty much every field of human endeavor that doesn't involve direct competition and/or immediate survival. Incompetent people who aren't aware enough to realize they are incompetent, hiding behind soft-standards and "this isn't as easy as it looks". (Direct competition or immediate survival tend to eliminate this. You can't easily fake competence in warfare, unless the enemy is doing the same.)
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 26, 2008 at 8:30 am
David O (6/26/2008)
JeffHave you consider decaf?:w00t:
David
Heh.. oh sure... but it's just like a developer who can't program worth a hoot.... "Why Bother?" 🙂
I'm sorry... I don't mean to be so nasty about this... The problem is that I've had all sorts of people with (supposedly) degrees and certifications and a pot wad of "experience" apply for jobs at my company... and if common sense and programming ability were gasoline, they wouldn't have enough to run a sugar-ant's mini-bike through a match box. :hehe: The problem is that the supposedly intelligent managers at my company keep overridding me and hiring these dummies. They're hiring based only on what the resume says... not on what happens in the technical interview. I don't know why the even bother with a technical interview.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2008 at 9:01 am
The problem is that the supposedly intelligent managers at my company keep overridding me and hiring these dummies. They're hiring based only on what the resume says... not on what happens in the technical interview. I don't know why the even bother with a technical interview.
And there is the root cause analysis for the issues you face. This is an unfortunate fact of life in many places. Targeted interview or resume wins of technical interview. Sometimes you get a diamond, many times it is cubic zerconia. :w00t:
You could go to your bosses and propose the idea of a DBA doing code quality exams and explain they improve performance, can reduce unexpected downtime and overall produce a better product. Then suggest you hire someone or they give you a raise while explaining the benefits. Win/win if you do right. Plus you can vastly reduce your headaches before production.
June 26, 2008 at 9:15 am
In my mind, the bigger problem isn't that bad code occurs, or that sloppy developers put it out; the bigger problem is that it's allowed to continue to occur, over and over again. Having dev teams with no hand in their own QA, with ugly dev schedules, and the overbearing "publish or perish" mentality means fastest coding method wins every time. Screw doing it right, forget about doing it intelligently, just do it fast, and pass it on to the next lower level.
Institutionally-sanctioned sloppiness is something very hard to get through, and impossibly without at least acknowledgement from the expensive seats that they've so far allowed it to happen.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 26, 2008 at 10:16 am
Matt
I love the phrase "institutional sloppiness". I've officially stealing that from you.
David
June 26, 2008 at 10:17 am
Go for it! :hehe:
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 30, 2008 at 5:34 am
Jeff Moden (6/24/2008)
jimige257 (6/24/2008)
Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.And, THAT is why I tell folks that every piece of code they write should be right right out of the gate! 😉 It takes a lot less time to write good, solid, well documented, performant code up front than it does to write a piece of crap, having it fail or cause a performance problem, having someone troubleshoot the problem to find the code, someone troubleshoots the code, and then fixes it WRONG again because they're still in a bloody hurry. Slow down, do it right the first time. If it takes you 60 minutes to write crap code, it'll only take you 70 minutes to write right code. 😉 Stop making excuses, folks... and stop whining about schedule... just do it right and the schedule will quickly lighten up because you won't be fighting so many crap code fires in production on top of everything else you're doing.
Yeah, I'm late to the game (Webelo's Resident Camp, who wants to learn the Ukelele Song?).
Jeff nails it here. Absolutely. There isn't a good excuse to write bad code. There just isn't. Bad code doesn't take less time, it takes more. Bad code doesn't save you time, it costs. The "later" that is intended to fix the bad code usually occurs in production under pressure with multiple VP's standing behind you asking why everything is down and the company is losing money. That's not the time to start pointing out the 1/2 hour you saved four months ago.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 30, 2008 at 5:39 am
One thing not mentioned is the use of copy & paste. We have a project that's actually, honestly, a little complex. In one place, we found we needed a query hint, KEEP FIXED_PLAN. We also found a different place where FAST 1 made a real difference in performance. Our developers saw these and copied them on to EVERY SINGLE STATEMENT in the system. The DBA with them was junior and he didn't catch it. I saw it when it was already in Production and causing all kinds of problems. We're still rewriting these procedures and finding developers in the company that thought they were supposed to put the hints on every query... It can make you insane. But it's a sign that a lot of developers aren't thinking about stuff, they're just copying what went before them. I know that they've run into similar issues in their VB & C# code.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 30, 2008 at 7:55 am
Grant Fritchey (6/30/2008)
One thing not mentioned is the use of copy & paste. We have a project that's actually, honestly, a little complex. In one place, we found we needed a query hint, KEEP FIXED_PLAN. We also found a different place where FAST 1 made a real difference in performance. Our developers saw these and copied them on to EVERY SINGLE STATEMENT in the system. The DBA with them was junior and he didn't catch it. I saw it when it was already in Production and causing all kinds of problems. We're still rewriting these procedures and finding developers in the company that thought they were supposed to put the hints on every query... It can make you insane. But it's a sign that a lot of developers aren't thinking about stuff, they're just copying what went before them. I know that they've run into similar issues in their VB & C# code.
I've seen the same thing happen when someone discovers "all the wonderful performance benefits" of "with (nolock)" and just goes crazy including it in everything. (I think every DBA has seen this one.)
Some people spend the extra effort to understand a system and how it works. Some people just apply what I call "professional rituals". They've been taught the magic words and the mystic gestures, they know that when you say "waz zug cho cthulhu", you have to turn around widershine three times, with one hand in the air and the other hand holding your right ankle. (Translates to "'from' has a table, then has 'nolock', then a letter, and that letter is what you use for the table in the rest of it", in the "SQL rituals".) It's like people who reboot their computer any time it does "something strange". Even if that "something strange" is it suddenly starts blasting pop-up adds at a thousand pop-ups per second. (What? You didn't know that rebooting is the right way to get rid of adware?)
Rituals are easy to memorize. Understanding a system takes a lot more work.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 30, 2008 at 7:58 am
Antares686 (6/26/2008)
You could go to your bosses and propose the idea of a DBA doing code quality exams and explain they improve performance, can reduce unexpected downtime and overall produce a better product. Then suggest you hire someone or they give you a raise while explaining the benefits. Win/win if you do right. Plus you can vastly reduce your headaches before production.
Shoot... I already do code reviews... nothing goes into the database unless it has my approval on it...
The bad part is, embedded SQL... in order for these dummies to get around a code review, the do the damage in Java. Now, I have to beat the ears off the managers yet again and get them to realize what's going on and to start doing code reviews for all Java code!
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2008 at 8:01 am
Matt Miller (6/26/2008)
In my mind, the bigger problem isn't that bad code occurs, or that sloppy developers put it out; the bigger problem is that it's allowed to continue to occur, over and over again. Having dev teams with no hand in their own QA, with ugly dev schedules, and the overbearing "publish or perish" mentality means fastest coding method wins every time. Screw doing it right, forget about doing it intelligently, just do it fast, and pass it on to the next lower level.Institutionally-sanctioned sloppiness is something very hard to get through, and impossibly without at least acknowledgement from the expensive seats that they've so far allowed it to happen.
Man... you should run for office! What a perfect way of describing the problem. Someone else said they were going to steal the phrase "Institutionally-sanctioned sloppiness" from it... Not me... I'm taking this whole thing as a quote and I'm going to email to the managers I have that understand the cost of everything and the value of nothing. Well said, Matt!
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2008 at 8:07 am
GSquared (6/30/2008)
I've seen the same thing happen when someone discovers "all the wonderful performance benefits" of "with (nolock)" and just goes crazy including it in everything. (I think every DBA has seen this one.)Some people spend the extra effort to understand a system and how it works. Some people just apply what I call "professional rituals".
Dang.... that's exactly what they did at the place I work... the worst part is... the DBA recommended it! 😉
It works for us just because there's so very much crap code that it sort of helps... it would take years to rewrite all the 12 years of crap code. We're working on it... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply