This piece was originally published on Sept 21, 2009. It is being re-run as Steve is away on sabbatical.

I ran into this blog post about IT v other workers. The post is in response to an article in Slate about workers being oppressed by their IT departments. They're both relatively long reads, but the summary is that a writer at Slate thinks that the technology departments are too restrictive and unnecessarily hindering workers. The blog rebuts that point with the notion that many technology workers don't understand the complexity of their systems and there are valid reasons for not allowing workers to have free choice in what applications they install.

Having been in a number of technology departments, from small to large, I can say that I see both sides.  On one hand technology departments spend a lot of time and money cleaning up mistakes and problems from users. On the other hand, new applications and enhancements can often increase the efficiency or effectiveness of workers that find a new way to do their jobs.

The problem in both cases is a few extremes are being chosen to  represent both sides. Most users don't  require lots of attention from IT for their machines. And most IT solutions punish everyone for the problems that a few people provide.

I think that as DBAs we sometimes start to feel this way about developers. We classify them all as problems and give them no rights, or we think that every person must have all rights to all instances. This extreme set of solutions isn't practical, or effective, for most organizations. As much as I might seem to hate developers and make fun of them in these editorials, I recognize that there are many talented programmers and quite a few that know more about SQL Server than I do.

The best way to handle rights and access is to selectively apply permissions to individuals, matching up their skills with their rights. If a user has problems creating indexes or adding tables, remove those rights. If they are a model DBA, then perhaps they deserve sysadmin rights. You can either loosely apply security and then tighten it up or lightly apply it and loosen it as people prove themselves.

Let me say that I still highly recommend the use of roles for the actual implementation of permissions, but don't view security as a set it and forget it. You should re-evaluate it periodically, and that would include the permissions you give to your co-workers.

Steve Jones