You’re Doing It Wrong – Database Standards

Having standards is important. If you don’t believe me, just ask your spouse or significant other.

Knowing that such things are important I am willing to wager that your company has spent time putting together a set of standards to be followed with regards to application development, including database standards.

I’m here today to tell you that database standards can often be perceived as a huge waste of time (and money).

Let’s look at some reasons why:

Standards are often ignored in a fast-moving environment

And in slow-moving environments as well. In fact, they get ignored any time a developer complains to a manager that the standards are getting in the way of some widget being deployed on time. Phone calls are made, voices raised, and concessions are made for a “one-off” exception. Before you know it you have a whole enterprise full of “one-offs”. The main reason for this?

A mismatch of incentives, that’s why.

Bonuses and raises are tied to performance. Not getting that widget deployed is likely to result in a negative performance review. People will naturally want to push forward even if it means not adhering to an already agreed upon standard. It’s their way of using the standard as leverage; they can assign blame for not getting things done.

Instead of motivating people to get things done by adhering to standards, they get motivated to just get things done by any means necessary.

There is nothing permanent except change

Your company spends time researching the best way to separate object name parts. They look at things like First-Name, First_Name, First Name, and even FirstName. Months are spent toiling over which is the right way for all development to be done because, as you know, this is important stuff to decide. Finally the decision is made to use an underscore.

Two months later someone on the business side decides to buy a new application, and that application uses a hyphen. Soon new in-house development will use hyphens as they build connections into that application. This will make it more difficult for you to enforce your standards, rendering the time and money spent on choosing the underscore as something you have lost and will never get back.

Things change. That’s what they do.

People are not diamonds; they don’t last forever

As new members join a team they are not familiar with the standards defined by the company. I once watched while a company spent time/money/effort on researching if they should use Java or C# as the default programming language. The decision to use C# was made and within six months we found new production code being deployed in…you guessed it…Java! How did it happen? Because someone new to the team told their manager that it would be faster for them to use a language they had experience with (Java) as opposed to learning something new. The manager loved this idea (and what manager WOULDN’T, right?) and that was the end of our standard for using C#.

I am willing to wager that the above three items describe 99% of all IT shops in the world. I suspect the only counter-examples are places like NASA and the military, where standards are in place otherwise people are likely to die.

However, I *do* recognize that having standards is a good thing. So, what can you, in the 99% of IT shops that suffer from the items above, do to help? You want to develop standards that offer value, and that people will want to follow. You can get this done by having your shop adopt the following standards right now:

1. Use what works

If you try to adhere to one thing, like using only C#, then you are limiting yourself to other solutions that may suit your needs better. It’s best that you hire yourself an architect with experience in a variety of systems and can help you understand the costs, benefits, and risks associated with all options. Your standard should be this: Use what works best for your company at this time. It’s not rocket surgery. Things will change, remember? Be willing to change with them.

2. Always expect garbage

Your code needs to be able to handle garbage. A very common (and I would dare say novice) mistake by developers is expecting inputs (and outputs) to be perfect. They are not going to be perfect 100% of the time. At one point I never had seen a database with a hyphen in the name, and as a result my code reflected that. And then I met Sharepoint. Lesson(s) learned. Your standard should be this: Always expect garbage.

3. Send a note to future you

No one has any idea what your code is doing, including you. Why not write down a comment or two in an effort to explain what you are doing? When you are trying to fix something at 3AM those comments and associated metadata can come in handy for anyone, especially yourself. The standard here is simple: Send a note to future you. Tell yourself (and others) what you are doing. If you cannot do this, then you don’t understand the problem you are trying to solve with your code.

4. Blame no one

When things go wrong the reaction is for people to make certain that (1) they can find the root cause and (2) the root cause isn’t them. This leads to an awful place where people only put forth enough effort to avoid taking blame for when things go wrong. If people were allowed to function in an environment where they knew that blame was not something to be concerned about then they are likely to perform better. The standard for all teams, business and IT, should be this: Blame no one. The end result is a positive environment that fosters a sense of true collaboration.

5. Be responsible

If the issue is your responsibility (note I didn’t say fault) then stand up and tell people you will get it fixed. Take ownership. If there is something to be done, and you can do it, take the responsibility. That should be the default standard for any team, anywhere, doing anything: Be responsible. This goes along with the previous point, too: don’t look to just pass blame along.

There you go, five standards that should be a part of any team, anywhere. Tell your company to stop wasting time and money on developing standards that get ignored. Take the five items I just listed and deploy those as your standards from this point forward and you’ll be in a better place in 18 months. Probably sooner.

Trust me. I’m an expert.