There's a common trait in developers that if they didn't write something then it must be rubbish.  Usually this is just a symptom of not taking the time to understand what the software or library does well and working within those boundaries.  OK, I'll admit it, third party software doesn't always meet your needs and sometimes it's just awful stuff, but if it's from a commercial vendor (and Microsoft in particular) then you can be pretty sure that it will improve over time and that while you might need to implement some workarounds to get the job done it should meet your needs.

So it's a shame then to see people like Joel Spolsky espousing the Not Built Here syndrome, and passing it off with a tone of self righteous elitism.  And what was it that they decided to reimplement? It was SQL Server Mirroring!

Now let's put things in context.  There are 3 reasons listed for writing their own mirroring solution, 2 of which are quite legitimate and relate to performance limitations - a fair reason for taking on something that will likely be obsolete when SQL2008 is released.

But reason number 3 is "The database mirroring technology is rather new and therefore feels more like a black box."  If that's not a classic symptom of "Not Built Here" I don't know what is.

What would be a better approach?    Well, if SQL was so bad - why not look at Oracle, or another alterative.  Or if that wasn't viable, taking the time to understand what they would be trying to replace before jumping in and replacing it.  The end decision may have well have been the same, but it would have been based only on logical reasons - not 33% gut feel.

I'm interested to hear your thoughts on this one.