Originally posted at http://www.bidn.com/blogs/JEBacaniSQLDude/ssas/1342/t-sql-tuesday-13-from-a-sql-server-developer-s-point-of-view...
So I saw the topic this time around for T-SQL Tuesday #13 as “What the Business Says Is Not What the Business Wants”. And then I read the fine print of “What issues have you had in interacting with the business to get your job done?” After seeing this, I was determined I needed to chime in and add my two and half cents…
You see, I am a SQL Server Developer. I am not a DBA. I have some DBA power, but that’s a topic for another post… However, I do not perform back ups nor monitor SQL Server traffic or such. Instead, I develop applications that work with SQL Server, and recently more often, I troubleshoot existing production applications that use SQL Server. As a developer and more importantly, as an IT Professional, I take pride in the work I do because I follow the concepts of the SDLC-- the software development life cycle. More specifically, I like receiving code specifications and requirements via BRDs (business requirements documents) or help desk tickets, and I like following change control policies of ensuring code deployment of the work I do performs and works correctly when deployed across development, QA (quality assurance), and ultimately in production environments.
What the customer/business really needed…
But here’s the thing. The business wants something done right away. Correction… They want it yesterday. So what do we often do? Well, in my experiences, I have seen IT development teams slam code directly into production.
Slamming a square peg into a round hole… The IT way?
The developer even has direct access to make changes in production, to either implement code or business processes directly, or even to affect data changes to SQL Server! “OMG!”, right? “Say it isn’t so!” But yes, in the small shop I work with, it happens. And it happens because the business wants it to happen.
But isn’t it the same business that’s telling IT to follow proper procedures? Isn’t it the same business that’s telling IT to have separate roles where only DBA's have production data access and not developers? Isn’t it the same business that’s telling IT to test and ensure all applications work properly before being deployed? Why, yes it is.
Just say no to the SDLC!
Don’t get me wrong. The business is not solely to blame on this; IT is not absolved of their involvement. But it takes IT… It takes SQL Server professionals to make a stand and declare such direction as wrong and not possible. Sure, the risks must be weighed against the business need, but following SDLC and following change control isn’t simply a topic in IT Management school; it’s sound policy that allows us SQL Server professionals—DBA and Developers and all—to have the ultimate pride in our work.
So again, what issues have you had in interacting with the business to get your job done? Well, it’s not about getting the job done. To me, it’s about getting the job done properly and correctly.
How the programmer/developer wrote it.
Oh. As part of my two and half cents, I am sure many of you have seen this, but do check out The Project Cartoon site at www.ProjectCartoon.com. That’s where the tree images come from. It’s a humorous view of projects and I think some of the images fit clearly with the topic “What the Business Says Is Not What the Business Wants”.
Thanks for reading!!!