Beware of NOLOCK hint
At many of the companies where I consult, use of the NOLOCK hint is ubiquitous.
In the normal situation , without NOLOCK, SQL Server places a Read lock on the rows that are read when you issue a SELECT statement. (These read locks are only held for the duration of the select statement.) Many teams have developed the habit of using the NOLOCK hint on all select statements. The NOLOCK hint tells SQL Server not to issue these read locks thus relieving SQL Server from having to administer these locks. The NOLOCK hint will look like this:
SELECT * FROM Customer WITH (NOLOCK) WHERE CustomerID=1
So far, so good. No Read locks, less overhead, more efficient server. Now here's the problem that I think most people do not realize: NOLOCK is equivalent to READUNCOMMITTED. That means that you are potentially reading dirty data! Read Uncommitted is the lowest isolation level and permits the connection to "read through" any exclusive locks held by another transaction and read the other transaction's uncommitted data. If you use NOLOCK, you may be reading records that may never get committed to the database or you could be reading inconsistent data. This may or may not be appropriate for your application.
I suspect what is happening is that teams are running into blocking situations and instead of finding and curing the source of the blockage they simply put in a NOLOCK hint, unaware of its potentially dangerous behavior. If you don't care about data integrity, then continue to use NOLOCK. If you do care about the integrity of your application, find and fix the blockage at its source and don't sweep the problem under the rug with the promiscuous use of NOLOCK.