Welcome to T-SQL Tuesday the thirteenth hosted by Steve Jones ( Blog | @way0utwest ). This month’s topic is “What issues have you had in interacting with the business to get your job done.” I’ve got two anecdotes to share.
The most common issue I’ve experienced is tied with reporting. From donor mailings to revenue reports, user requests always seem to fall a bit short of what’s needed to complete the task. One example is addresses: the user nearly always means to request a “good, preferred” address, and why shouldn’t she? Why would one request a bad, lost or former address for a mailing? But it’s that kind of jump in logic and expectations that SQL Server, and thus developers, can’t assume.
The way around this kind of trouble is good communication. Ask the user what she needs. Listen. And then ask more questions. In our shop, we’ve gotten used to these requests. When a user asks for an address, we know that she means “good and preferred.” The same is true for email addresses, phone numbers and other contact information. But that doesn’t mean that we don’t go back to verify our assumptions. Over the past two and a half years, we’ve grown accustomed to talking business needs with our users, but we always go back to verify.
The other issue that I’ve run into is user misunderstanding, and this is the confusion that is caused by the letters “D-B-A.” SQL Server is not a simple technology, and it’s obtuse to mainstream IT folks as well. For example, think about backups – most systems are well maintained from file backups, but it is impossible to restore from a copy of a database file.
The issue that this confusion causes is that there might be best practices that are not followed simply because the business doesn’t deem them necessary. In my shop, I’ve been told, “Database performance is not a priority.” This was early in my career as an accidental DBA, before I had the knowledge to set up basic performance tuning measures, such as index maintenance or stats updates. Now that I have this knowledge, I’m constrained in making changes because I’ve been explicitly told that it is not a priority.
This kind of confusion is also the most difficult to combat. One can spend a massive amount of time explaining the role of the DBA, or what performance maintenance can do for a system, and can even translate the cost savings into business terms for the Chief Officers of the company. But if even one small detail is lost in translation, then the whole project may wash out. In my experience, something has to break before any change can be implemented.
In both cases, however, communication is the key to change. Especially in the case of a misunderstanding around the technology – and if you’re in the job for the long haul – regular explanation as to the benefits, the costs, and how things work can help to spread knowledge about SQL Server in addition to warming up the decision makers as to changes for the betterment of the environment.
If you find yourself employed by a company that simply won’t listen, doesn’t seem to care about taking care of their data, don’t fret. Don’t get pissed off. Don’t get into fights. It’s not worth it and doesn’t change any of the business practices that have gotten in the way of your job. While it becomes an exercise in patience, ultimately it is the decision of the business – the folks that write your paycheck. Drop your concerns and documentation into a memo, email it to your supervisor, and let it go. The frustration isn’t worth your job.