Having spent most of the last three days doing releases and having to work around issues that shouldn’t happen, I think I’ve earned the right to some moaning.

Here goes, with some rules of thumb that should make all our lives easier.

#0 – Put your changes in source control

If they are not in VSS or TFS and are confined to your machine, they are not completed to anyone but you, regardless of how hard you’ve worked on them. It’s that simple.

#1 – Commit code that works.

Code that is checked in should have been tested and should work. “Tested” means merged with what was already under source control, compiled, and tested.

This involves getting the latest code, merging, compiling, testing, THEN checking in your changes. Manual merge is preferred to automated resolution when conflicts are found. This means, looking at the lines of code that are conflicting, finding out why the conflicts exist (were the lines changed because of some other requirement that was implemented by another developer?) Do not assume that the code coming from the server can be replaced.

#2 – Commit code that works (again)

This goes for stored-procedures and database scripts too.

Don’t be tempted to change scripts directly on the database. It takes time either way, so instead of typing a script directly in SQL Management Studio, check out the corresponding file from source control, make your changes, copy the content to SMS, run the script, and test the changes. If the script fails your tests, go back to the file and make more changes there. Rinse and repeat. Once the script passes the test, check it back in source control if it can go in on its own.

IF THE SCRIPT IS A DEPENDENCY to some code, check them in together. This is to prevent the situation where code comes to rely on database scripts that are not available yet. If the code and script are under different source control databases, for either one add a check-in comment referencing the changeset of the other; that will ease resolution of problems when they arise.

#3 – Do not check in commented code

Code comments are fine, commented code isn’t. Commented code is old and not needed, get rid of it.

If we need the history of a file, we can turn to the source control database.

#4 – Some mistakes are not mistakes

Sometimes it is blatantly obvious that something has not been tested. A typo on a keyword, for example, says a lot about how much, if at all, something has been tested.

#5 – Don’t take shortcuts

Well, sometimes shortcuts are necessary and OK when you know where you’re heading, but always strive to use the full duration that you have estimated for a piece of work. Use time left over for some extra testing or improving the code. If your work overruns, ask for extension with a valid reason, even if just to say that you did not appreciate how much effort was required. When shortcuts work, everyone is happy, but when they fail, you get blamed for them. And NEVER BASE ESTIMATES ON SHORTCUTS