T-SQL Tuesday #13: What The Business Wants

This month is the (lucky) 13th T-SQL Tuesday and is being hosted by Steve Jones (blog | twitter). Steve is asking about issues we've had interacting with a business in order to get the job done. Specifying project requirements often leads to the classic problem of "do what I meant, not what I said!". In my opinion, a lot of it deals with the spirit of what the business means. Here's a few examples:

The business might mean well, but not know what they're talking about. A while back I applied for a DBA position where the job description made it very clear that familiarity with transactional replication was essential. The interview reflected this as well, and a significant portion of it consisted of transactional replication questions. The interviewer explained to me that they have some rather "unique requirements" that make transactional replication essential, and proceeded to explain them to me. I told the interviewer that based on their description, snapshot replication may be more appropriate than transactional replication. They told me that the last DBA felt the same way, but the manager in charge explicitly specified to only use transactional replication. I'm willing to bet that the manager in charge probably only understood transactional replication, so they wouldn't allow anything else to be used.

The business might not mean well. Once upon a time, my team was working on adding some enhanced options for users, including the ability to "opt-in" to receiving marketing emails. The conversation with management went something like this:

Mgmt: Let's opt-in all the users to start with
Us: But then that's "opt-out", not "opt-in"
Mgmt: No it isn't. We're opting-in all the users automatically and letting them know they can opt-out at any time, so it's "opt-in".
Us: OK – let's review the concepts of "opt-in" vs. "opt-out"…
Mgmt: We're still going to opt-in all our users and let them opt-out if they want.

The business might not even care. I can think of a few times where I've been told to "just start coding" instead of taking the time to plan things out and do it the right way. After all, trying to think things through is just a waste of time, right? When I pushed back at management for this, I was told that "[their] bonus depends on getting things done, not getting things done correctly."

I consider all of these cases to be "extreme", but a great solution to many of these problems involves two-way communication. If both sides are talking and listening to each other, the chances of things getting to the point of ridiculousness are greatly reduced.