Tim Ford, aka SQLAgentman, posed a question: when you think you know why something’s not working, when do you modify somebody else’s code, and when do you refuse?  I know, I know!  I’ve got the perfect answer – “It Depends.”

Vendor Apps That Are Under Paid Support

I never touch vendor applications when I’m paying maintenance contracts.  It’s not that I want them to do their job – although I do.  It’s not because I’m lazy – although I am.  The reason is simple: I don’t want to be thrown under the bus later.

If you’re working with an application and you think the database schema was designed by monkeys banging on typewriters, don’t even think about changing the database schema yourself.  If you do, guess what happens when the next version or service pack arrives?  The guys who designed the schema are probably the same guys who designed the installer.  I’ve seen installers that run T-SQL scripts that absolutely depend on the schema being completely identical to the way it was last time.  If there’s any variations, the installer throws an error, and you’d better believe they’re not handling errors correctly either.  It leaves your database in a completely messy state, totally unsupported by the vendor, and then the blame game starts.  You’ll get the shaft, because you tweaked their schema.

Nobody will remember how you made the database faster.  Everybody will remember the DBA who couldn’t keep his hands out of somebody else’s code, and borked it.  Doesn’t matter if you’re right: you’re only as good as your customers think you are.

Vendor Apps That Aren’t Under Maintenance Contracts

Maybe the vendor’s gone belly-up, and you’re just trying to keep the product running.  In that case, sure, modify the schema.  You’re going to own the support yourself anyway. Just make a rollback script right then and there before you do it, and save the rollback script in case something else goes wrong later.

Maybe your company’s about to go belly-up, and you’re not paying maintenance on anything.  In that case, sure, modify the schema, because you gotta do whatever it takes to keep the trains running, or you’ll be laid off for not playing along.

In-House Applications

If the development team consists of people on your payroll, then this is your chance to show value within the company.  Quickly document:

• What needs to be done
• Why it will improve performance
• What you’d do if this DOESN’T improve performance
• How long it’ll take to do
• When it can be done (right now, after hours, only at month end, etc)
• Who can do it (but not who SHOULD do it)

Lay these points out as quickly as possible, in as short of an email as possible, and send it to the product managers.  For that last bullet point, I usually say, “I’m totally fine with doing this myself, but I wanted to communicate it to the team in case someone else would like to do it or wants to sit with me while I do it in order to learn more.”

You want to be as friendly and upbeat as possible, because you’re basically pointing the finger at somebody’s baby and calling it ugly.  Be a part of the solution, not a part of the precipitate.

Open Source Applications

This process is almost guaranteed to fail long term, but it works short term:

1. Modify open source code
2. Put it into production in your environment
3. Try to get it into the trunk branch (the public repository of modifications)

This process is almost guaranteed to work long term, but it can take a while:

1. Modify open source code
2. Try to get it into the trunk branch
3. After it’s released, put it into production in your environment

Try the first route, and you might fork the code and be forever patching your stuff.  I’m a fan of set-it-and-forget-it.  Mostly the forget-it part – I’m a really big fan of that.  So I’ve been burned by tweaking open source code, forgetting about my changes, and then upgrading to the latest version.  Surprise, my stuff is borked, and there’s nobody to blame but me.

Who I’m Tagging

I’m curious to hear what StatisticsIO and Kevin3NF think, especially Jason since he’s done open source work.