One would think that I might read the complete directions before I get all crazy and start posting things, In this case well, not so much. I think I was so excited about the last T-SQL Tuesday and was ready to do another one that I saw the question and was ready to post away. So I posed a week early, and I then deleted the post, and I will repost this on the correct day. So maybe I should really change my answer this week to… Read The $%^@! Manual Chris.
From Steve Jones about this topic:
“I was giving a presentation recently and someone in the audience started to ask about why I recommended against a certain technique. Without getting into it, this person kept saying that she had to implement things her way since the “business” said they needed it done that way. However a little digging showed that the business didn’t really understand the technology. They were asking for a result, and she took them literally in how she implemented a process. A classic impedance mismatch.
I think we’ve all had situations that are similar. The business, the client, the customer, is asking for something, but they don’t know how to ask those of us building the technology. Or they don’t understand the implications of asking for something like “absolutely zero data loss” to be implemented.
The official topic this month is:
What issues have you had in interacting with the business to get your job done.“
The sad part here is I don’t know where to start or where to stop. If many of the companies that I have worked for knew what they wanted I am sure that the road would be much easier to travel. The best example that I can give is when a Delphi programmer was assigned to a director position but kept on developing. He then in turn hired his first DBA, and in the interview made the obvious mistake of saying he wanted a complete lock down of the database. His exact words were, “I want a Soup Nazi, like on Seinfeld, but I want that in our database. I want a Database Nazi”. Yet it took years before we could even start to make any changes to the security. I had some of the developers actually get up and walk out when they were not allowed to make changes to the production database schema. Now this may have even been somewhat acceptable, if it were a small company that could make changes at the drop of a hat.
This is a public company. One that is still traded to this day, and to top it off that director still works there and still has access to production to make changes in the database at will. Last I heard he was promoted to Data Architect because of his in-depth knowledge. The operations team says he needs to develop elsewhere yet he is determined to have access and work in production. He wants the access without the responsibility.