THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

James Luetkehoelter

Nearly any SQL topic presented at times in a slightly eclectic manner.

Who out there writes perfect code?

Recently I've been working with a lot of code, TSQL, .NET, report design, etc. that has just made me scratch my head and say to myself "what were you thinking". Well, after reviewing my own work in the last five years, I feel like a schmuck. The farther back I go through the thing I've done, the more I think "who wrote this mess" - with at least some aspect of it.

It's easy to analyze or critique someone else's work. The reason its easy is that you're looking that work out of context. And by context I mean all of the other little things that drastically affect the work we do:

 1) Dictated requirements: This has been discussed before on this blog, but really one of the worst things that make you cringe at your own code years later are requirements established by someone that has no idea what the requirements should be. One of my first questions when undertaking anything (even just designing a report) is to ask the business sponser "What business question/problem are you trying to answer/solve with this [report|tool|glob of code|process]." For those of you that ask that question, you know it isn't easy to get an answer. Often any tenacity you show on this front gets shut down by some personal or political agenda. You end up writing something you aren't happy with. That's life in the real world I guess.

2) "Patterns": Every organization does thing a little differently. Every so often a design or programming pattern gets established that really isn't the best approach, but it remains in place because it is the "standard". That pattern or standard continues on with a life of its own, surviving employees and managers. Before you know it you have a code base that new arrivals shake their head at, but its not so easy to just "undo". So the new person gets sucked into the bad patterns, and they live on.

3) "Habit": I'm guilty of this one. People will get into coding habits. Maybe they're use to writing queries using temp tables and never took to table-level variables or CTEs. Maybe the use IN where they should really be using EXISTS. Believe it or not these habits can be very hard to break. People are reluctant to try new things when they have a technique that works; convinces others to use a more efficient technique can be even more difficult.

4) "Deadlines": I'm sure we've all been burned by this. A deadline for a project is put in place regardless of what timeline is appropriate, and we end up cutting corners and writing code we swore we'd never write, just because some has decreed "It must be complete". Yes, this is silliness, but its reality.

So while there are legitimate times to ask "what were you thinking?", try to take it with a grain of salt. Try to understand what context whatever "piece" you're looking at existed in. If you find no logical reason why something should be written "oddly", go ahead and say "what were you thinking". But make sure you take the time to learn the context...

Published Monday, June 21, 2010 8:28 PM by James Luetkehoelter



V.M. said:

I keep seeing on the twitter SQL people that keep talking about how other DBAs, developers, vendors, etc write bad code and how they are "perfect". And I keep laughing to myself - as I always think they are full of sh... :). My experience is exactly like yours and I totally agree with your comments. Me, or somebody else wrote that messy code because most likely there was a reason, just like you explained. And when project timeline permit, I do like to rewrite/fix existing code and make it cleaner and more readable. But then I add some fixes, some business changes and code is not perfect again.

So yes, I totally agree with you and I learned to always respect other coders code and assume that they wrote it like that because that was the best they could do in current circumstances.

June 21, 2010 9:50 PM

bob said:

Reminiscent of this article from Coding Horror:

"In fact, I think you can tell a competent software developer from an incompetent one with a single interview question:

   What's the worst code you've seen recently?

If their answer isn't immediately and without any hesitation these two words:

   My own.

Then you should end the interview immediately."

I'm never satisfied with my SQL procs though most of it is a result of the language.  It's simply cumbersome.  Oracle's PL/SQL allows a more elegant approach to many problems but even then:  it's still SQL.

June 21, 2010 11:14 PM

Adam Machanic said:

Try as I might, I can't agree with that one, bob. I work very hard for my customers to write the best possible code I can, and I'm often quite satisfied with the results, even (especially!) in my T-SQL stored procs. Does this mean I'm incompetent, or just that I'm anal retentive about quality and have spent an inordinate amount of time learning how to do things properly?

I'm pretty sure it's the latter at this point, because my code tends to both return the right results and run a lot faster than the often subtly messed up and slow code written by some of my peers, who use excuses about the language being too difficult to work in, etc, etc. If someone believes that the worst code they encounter is that of their own creation, I posit that the person needs to learn how to do a better job, or maybe find a different career.

June 22, 2010 10:19 AM

James Luetkehoelter said:

Well this went in a direction I didn't intend...

All I'm trying to say is that when you encounter really cruddy code, remember it has a context. There are certainly different quality levels in developers, and even in the same context may produce dramatically different (in quality) results. I have a tendancy to look at something ask "what were you thinking", but just wanted to take a step back and really ask it rather than juat a rhetorical question. Yes, poor developers usually lead to poor code, but even good developers with insane constraints on them end up producing less than optimal, even "odd" code.

And no TSQL vs PL\SQL wars please :)

June 22, 2010 11:15 AM

Adam Machanic said:


I don't agree. Crap code is crap code. Crap constraints combined with a developer who cares enough to deliver the very best should result in--at worst--great code that does something odd. And by great code I mean code that is well formatted, follows as many best practices as possible, and includes a huge comment block stating exactly why the "odd" behavior is necessary. Otherwise, it's just crap code.

June 22, 2010 2:17 PM

James Luetkehoelter said:

Believe me Adam, there are people out there that care walk into a constraint that results in what I would call crap code, even though the developer knows better.

Example: I recently worked with an organization that had an insanely restrictive DBA. All of the developers were forced to work with a handful of views (each with 50+ joins each) which they were forced to create. They were full of only marginally necessary outer joins, IN and NOT IN clauses instead of EXIST/ NOT EXIST (because the DBA thought that the EXIST clause was "suspect"), lots of things that make us cringe. The DBA was the son of the CIO. Any attempt to question the approach or developer something more efficient was met with flat out denial. I ended up walking out of that one (saying "I can't help you if you don't let me help you").

There are plenty of good people out there trapped in these types of situations.

June 22, 2010 4:26 PM

Martin N said:

Have to say I agree with both Adam and James on this. You don't always have the freedom to design the most optimal solution (time, budget etc..)... BUT you should do the best you can and write a decent comment block explaining the context for the next poor sod who has to take a look at it...

June 23, 2010 6:27 AM

Mike C said:

#1 is a biggie for me.  I hate having to write something I know is dead wrong because I'm being forced...  but it does happen, and I just document the heck out of it in the code

June 23, 2010 6:47 PM

Dave F said:

People who dabble only in SQL tend to develop a lot of affectations, just like spoken language, that does not make sense to others not familiar with the vernacular. This includes most DBAs. On the other hand, those who produce good code do so no matter what the dialect, system, conditions, and so forth. This includes some DBAs who are excellent no matter what they do.

June 26, 2010 2:15 PM

Dave Millar-Haskell said:

James' point is well-taken. I've looked back on my own code and seen room for improvement. I'll add a reason to James' list: I was learning the language/platform and needed functioning code in a timeframe more suited to an experienced programmer. I appreciate Bob's perspective. When I get to the top of the heap and write great code just because I always do I hope I don't realize it. Humility is an appealing quality in a person generally, not just in a job interview.

June 26, 2010 6:54 PM
New Comments to this post are disabled

About James Luetkehoelter

I am passionate about what I do - which is DBA, development, IT and IT business consulting. If you don't know me, haven't met me or have never heard me speak, I'm a little on the eccentric side. One attendee recently described me as being "over the top". Yup, that about says it - because I only speak on topics that I'm passionate about.
Privacy Statement