When all you have is a hammer, everything is a nail. For the folks at TCTSRN, all they had was a 20 ounce ball peen called T-SQL to solve their IT problems. That’s fine if all you need to do is generate file extracts or shuttle data from one source to another behind the scenes of an enterprise application that had a front-end. But after a few years, the TCSRN users started to demand more, like custom intranet applications. If you have been doing nothing more than data-diddling for a long time, you are woefully ill-equipped to deliver anything more than crap to the end-user.
I was trying to get that point across to my team – they didn’t know shit, and they were going have to get with the program. I was more than willing to show them the way, mentor them, coach them, whatever. But they where going to have learn something more than SQL.
They didn’t like that idea.
For one, SQL is a procedural language. It’s great for linear thinkers. The code at the top runs before the code at the bottom. Nice, top down paradigm.
Secondly, you could keep monkeying with a query until you got the results you wanted. Hit EXECUTE, and you get instant gratification.
So, with the nice procedural nature of SQL, and the immediate results that show up in your editor when you hit F5, it becomes a very comforting programming environment. Sort of like a application development security blanket. Always there. Stable. Controllable. Complex enough to keep you awake. But even if you are trying to solve complex data issues, all you need to know is the basic syntax, and you could hack your way to a solution. The language hasn’t changed in over a decade.
But developing applications requires more. Event-driven programming, object-oriented programming, multi-tier development, remoting, etc. – some of that is hard shit that requires some creativity, tenacity, and curiosity. My team had none of those traits.
This became painfully evident when Mr. Whiteboard asked me to work on a web project with the TAC (Thick-Accented-Cambodian).
“I don’t want you to do the coding, but help him out,” the shovel-faced bozo had asked me.
That would be rather tough, I had thought to myself, since the TAC had never coded anything but SQL. But I took it as an opportunity to demonstrate how things can and should be done in the shop. This would be the app that I could leverage as a learning exercise for the team.
On the surface, it was a simple page that queried the massive back-end system, combing through millions of records to return just few, depending on the specific criteria the user entered. With the brute force approach of building a dynamic query and passing it to a stored procedure, it would take minutes to return a result – a worthless solution. But with some sophisticated front-end work using AJAX, a solid middle-tier object that does the bulk of the processing, and a basic stored proc that returns small recordsets, the app would rock.
Not that the TAC was going to be able such an app – he was a SQL-writing idiot who knew one way of doing things – brute force. His stored procs sometimes where 5000 lines long. He thought temp tables were a gift from the heavens – and fancied himself to be a genius for knowing how to use them.
Get a clue, you data-diddlers – temp tables are no big fucking deal. If not used properly, they are just a way to get yourself in more trouble. And most of you are really lacking in the creative side, so I see a lot of brute force in those nasty stored procs you SQL hackers are so proud of. So many of you write like you get paid by the line of code. The rest of us are not impressed – after all, there is something called elegant coding. But I digress.
To top it off, the TAC has a nasty habit of nesting sub-queries. His code looked a lot like this:
... And so on, and so on and so on…
YADA_YADA From TableYada Where YADA_ID IN (Select
YADA_ID From Where YadaYadaID IN (Select YadaYadaID
From Table YadaYadaYadaId)))…
You get the idea. It was like the TAK would curl himself up in a little ball of logic and fuck himself.
So I decided to lead by example. I came in on a Saturday (that was getting to be a habit), and wrote a nice prototype ASP.NET application that solved the problem. Leveraging some 3rd-party AJAX components (not some Atlas vaporware), I had a UI working in hours that queried that database and offered drill-down functionality without post-backs and excessive delays. It used one stored procedure that was twelve lines long.
I commented the C# code, excessively. I wanted the TAC to get the idea -- not everything can be solved by SQL.
It didn’t take long for me to figure out that the TAC was not impressed. I met with him the next Monday in my office.
“Did that code make sense?” I asked him.
“Uh, wud, the web page thing?”
“Yeah, notice how the middle-tier database code reduced the round-trips?”
“Uh, ummh, maybe,” he stammered. “But maybe, uhmm, it not so good. Maybe you can make it stored procedure, so not so much C sharp code.”
Really, I thought? Little shit-for-brains SQL boy thinks we need more spaghetti code…
Fuck, I was going to loose it….
“And how would we debug that?” I asked. “There are four levels of detail, each with its own query.”
“Uh, maybe you use PRINT statements,” he said. I realized that this marble-mouth cretin had never used a debugger. It was a lost cause. All he had was a hammer, and the world was one big nail to him.