So there I was, sitting across from this "DBA" who had managed to impress me with the depth of his knowledge regarding MS SQL Server, Oracle, Sybase and Postgres. He chatted on about their various histories, performance tuning, strengths and weaknesses and the little quirks you should know when dealing with each. Now, I can't say that I am much of a database expert, but this guy clearly knew his stuff. Then I asked him about normalization:

Uh, well, I know about the first, second and third normal orders (sic), but I can't say I've done a lot of that stuff.

Now, this wasn't a job interview. It was just someone I happened to casually meet and we were chatting about this stuff. If this was an actual interview, that last comment would have sunk him.

In chatting with our CTO, he tells me that this is something that he has seen this quite a bit in older DBAs. He claims that they worked in a time when space and CPU time were at a premium and therefore they didn't focus as much on "esoteric" concepts such as normalization. Newer DBAs, he claims, have the luxury of throwing lots of high performance hardware at a problem and are therefore more likely to be able appreciate the benefits of normalization. Frankly, I don't know enough about the topic to weigh in on that debate, but I do know that poorly normalized databases make my life miserable as a programmer.

In another example, I was working on a program written before I was born (as of this writing, I am 34 -- no prizes for guessing the language). This program was an atrocious mess. The only subroutines that were used were ones that had been defined externally to the program. For flow control, a mass of goto statements had been used. I was complaining about this to another programmer (who was pushing 70) and he didn't understand my point. goto, in his opinion, was a wonderful tool to be used liberally.

Personally, I tend to mistrust younger programmers as many of them are hotshots who skipped college (confession time: I only have a two year degree). They often don't have a grasp that there are business considerations that have as much priority (if not more) than IT considerations. They sometimes think that using "$x=8;$y=$x+++ ++$x;print$y" in production code to set $y to 18 is okay because it's kewl¹. And testing? Testing is for wimps.

Contrasting that with older programmers, they are usually more experienced, have more patience and quite often are a ways behind the technology curve.

I don't mean to generalize too much. I've known older programmers who are always abreast of the latest technologies and younger programmers who truly care about putting out good production code. Unfortunately, while we search for a new DBA, the generalization seems to hold. Are my expectations too high? Is this frequently a problem with DBAs but less so with programmers or sys admins?

Cheers,
Ovid

1. We had an IS director who used 404 errors to serve images out of a database. He thought this was so kewl, he changed out corporate intranet to use 404's instead of proper URLs. It worked silently and no one ever knew ... until the Web server crashed horribly and lost a lot of configuration information. It tooks quite a while to try and figure out what the hell was going on.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.