June 27, 2011 at 1:06 pm
The DBA: The administrator handling 10s, if not 100s, of databases. Required by SOX to be a second person who rolls the first person's code so that a developer can't change production information without a second set of hands on it. Has little knowledge of what any particular database actually does other than pushing data out to something that requests it, and almost no intimate knowledge of its workings.
The Dev: The person with intimate knowledge of 2 or 3 databases, their inner workings, their oddities, and their algorithms. This is the guy who can't see prod but knows what the code is doing, but doesn't usually have access past DBO on his own databases in dev. Wait_Types and sp_lock are forbidden to him, don't even mention running a trace.
So, who owns the production code? Is it the DBA, who can see and access it? Remember, this person has very little knowledge of how the database works and its datapathing and the like. He's probably never seen the requirement specifications, but has access to all the tools under the hood to be able to locate a problem that's not logical but physical. He's rolled code every night and while a cursory glance was probably taken, he's forced to rely on the developers for efficiency and use security to limit their effects and/or mistakes to their own domain. Does this person OWN code that he doesn't understand intimately, is unfamiliar with the data flow, and interfaces with users he's never seen nor does he know what their requirements are and can thus prioritize issues?
Or is it the Developer, who can't see the data the logic might be choking on without a DBA interface and has no ability to determine concurrency or environmental issues? He can't run a trace to find the problem queries, needs an application specialist to determine what all is even being called if, for example, the webpage is failing, and can't do anything to affect a production issue directly anyway. He should be involved in logical changes causing issues, but does he OWN production code that he can't see, can't affect, and can't troubleshoot?
This mental deadlock is actually being generated by a conversation I was recently having with Jeff Moden on these boards. In particular, it was regarding procedure signing via certificates to allow for higher level access of certain procedures. Think owner inheritance just in a different method. Does the DBA, who usually lets security protect him because he doesn't have the time to intimately get involved with an individual project use this technique to own small components of the code, or does he trust the devs to do it properly (never!) if you're the one being called at 3AM when something fries? Or do you, as the DBA, make your Dev absolutely crazy and blanket deny these kinds of items, knowing the damage they can cause and not having the time (or possibly ability, not all administrators are high end developers) to make sure they do it properly each and every time?
Who owns the code?
I'd usually save something like this for a blog post backlog item but it really is more of a discussion then a dissertation anyway, so... discuss... :w00t:
EDIT: I should note, developer in this context does NOT mean an app coder working in the database. I mean a dedicated SQL DB Development resource who's quite proficient in his sphere.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 27, 2011 at 1:39 pm
I would say it's the Dev's (this is coming from a Dev by the way). If the Dev is causing issues, it's the DBA's responsibility to point them out and the Dev should make modifications accordingly. Maybe that's too simplistic, but that's my take on it. :satisfied:
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
June 27, 2011 at 1:51 pm
A DBA never owns code, Devs own code, the DBA is responsible for the environments the code runs in, especially prod. Ownership and responsibility could be getting mixed up here.
The Dev can see, affect and troubleshoot the code whilst its in test environments, thats what they are there for.
p.s. lets hope this can be discussed without descending into the usual DBA bashing 🙂
---------------------------------------------------------------------
June 27, 2011 at 1:57 pm
george sibbald (6/27/2011)
A DBA never owns code, Devs own code, the DBA is responsible for the environments the code runs in, especially prod. Ownership and responsibility could be getting mixed up here.The Dev can see, affect and troubleshoot the code whilst its in test environments, thats what they are there for.
p.s. lets hope this can be discussed without descending into the usual DBA bashing 🙂
That would be nice. See, here's my personal difficulty.
1) A Dev usually is locked down even at dev-server level so they don't develop solutions that won't work at higher levels. Try pulling your wait_type without access to master like this.
2) There are a LOT of tools out there that help the DBA, and could be useful to developers. However, for them to be put in place, the DBA either has to own the components that would allow for it, or has to trust his developers implicitly. Since under most circumstances, a dev owns the code, how or why should we assume DBAs are going to use these tools other then for their own maintenance and sustainability of the servers, of which are entirely administration oriented and thus actually owned by them.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 27, 2011 at 2:41 pm
personally quite happy to grant view server state rights.
It all depends on how many environments you have and who you share them with as to the level of access. It may work for a nominated 'dev' to have higher rights to smooth the flow of development.
I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.
---------------------------------------------------------------------
June 27, 2011 at 3:13 pm
george sibbald (6/27/2011)
I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.
Hm, I think you misunderstand me. I can accept either version. and have done so in the past. I'll have to think on how to rephrase it.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 27, 2011 at 3:46 pm
george sibbald (6/27/2011)
...I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.
I feel like the odd-man-out in that I apply release code to production and not the DBAs. Seriously, I fill out the change management forms which get approved by management and business but never DBAs. Once the CM is approved, I have a time slot with free-range in production to apply changes (and, as it turns out, to reverse those changes). I don't see why the DBA would do that anyway. They have all the servers and databases to manage and have no idea what business logic is going into the code.
______________________________________________________________________________
How I want a drink, alcoholic of course, after the heavy lectures involving quantum mechanics.
June 27, 2011 at 4:00 pm
toddasd (6/27/2011)
george sibbald (6/27/2011)
...I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.
I feel like the odd-man-out in that I apply release code to production and not the DBAs. Seriously, I fill out the change management forms which get approved by management and business but never DBAs. Once the CM is approved, I have a time slot with free-range in production to apply changes (and, as it turns out, to reverse those changes). I don't see why the DBA would do that anyway. They have all the servers and databases to manage and have no idea what business logic is going into the code.
Its a question of access normally, and we are talking about SQL development, not front end stuff. So, code that goes on the SQL server. As Craig says, DBAs dont understand the logic, but then they don't have to, they are a means to an end in this case.
Again, for me it comes down to where you draw the line on responsibilities rather than ownership, but perhaps that is just semantics,
---------------------------------------------------------------------
June 27, 2011 at 4:04 pm
Craig Farrell (6/27/2011)
george sibbald (6/27/2011)
I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.Hm, I think you misunderstand me. I can accept either version. and have done so in the past. I'll have to think on how to rephrase it.
Hmmm. I got the impression the real issue is you don't feel devs have the access they need to really test their code, so how can they accept responsibility for owning the code?
---------------------------------------------------------------------
June 27, 2011 at 4:13 pm
george sibbald (6/27/2011)
Craig Farrell (6/27/2011)
george sibbald (6/27/2011)
I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.Hm, I think you misunderstand me. I can accept either version. and have done so in the past. I'll have to think on how to rephrase it.
Hmmm. I got the impression the real issue is you don't feel devs have the access they need to really test their code, so how can they accept responsibility for owning the code?
No, that's a communication and facilitation issue at the development environment level, at least to me. Annoying yes, but that's not really what drove this question in my mind.
It's the ability at production and the direct split between knowledge and ability during a critical issue, or using tools that purposely avoid security lockdowns (execute as or signed procs, for example) with the blessing of someone who doesn't own the code but has to deal with the fallout, or you bottleneck all code by your couple of DBAs before they signoff on things so they now 'own' it, at least partially.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 27, 2011 at 4:17 pm
MY usual interpretation of ownership in this arena comes down to "who can make changes to the code".
In some cases, the DBA can make changes to the code - if she has been charged with providing a stored procedure to perform a certain task that the dev could or should not do - or, indeed, if the DBA needs to show the DEV how to do things in a more efficient / safer way - in which case, they could own that code - at least initially, although it may transfer at a later time to the DEV team.
In many cases though, the dev has to own the code for a business application and has to take responsibility for the integrity of that code.
I guess a very grey area would be database design, including but not limited to column constraints, which can affect developer code, but could fall more into the domain of a DBA.
The key to all this of course is that the company OWNS all of it and the individuals need to behave responsibly and communicate !
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);June 27, 2011 at 4:33 pm
Craig Farrell (6/27/2011)
george sibbald (6/27/2011)
Craig Farrell (6/27/2011)
george sibbald (6/27/2011)
I think you have to accept that in most shops devs will own the code but not the environment (and certainly not production). The DBA is needed to release code to production (not a fun job by the way) and make data available to the devs in a non-prod environment when issues have to be resolved.Hm, I think you misunderstand me. I can accept either version. and have done so in the past. I'll have to think on how to rephrase it.
Hmmm. I got the impression the real issue is you don't feel devs have the access they need to really test their code, so how can they accept responsibility for owning the code?
No, that's a communication and facilitation issue at the development environment level, at least to me. Annoying yes, but that's not really what drove this question in my mind.
It's the ability at production and the direct split between knowledge and ability during a critical issue, or using tools that purposely avoid security lockdowns (execute as or signed procs, for example) with the blessing of someone who doesn't own the code but has to deal with the fallout, or you bottleneck all code by your couple of DBAs before they signoff on things so they now 'own' it, at least partially.
Quick point - is 'bottleneck' the right word?
Sorry Craig, in the roles as you describe them I can't see anyone other than the Dev (or Dev team) owning the code, executed with elevated rights or not. Just my take on it.
---------------------------------------------------------------------
June 27, 2011 at 4:36 pm
george sibbald (6/27/2011)
Quick point - is 'bottleneck' the right word?
It's precisely the right word when you've got 3-4 DBAs supporting 80 developers. They cannot own anything, which is why signoffs on things running elevated require their direct review and approval, thus causing a bottleneck. New code is trumped by maintenance of existing code.
Sorry Craig, in the roles as you describe them I can't see anyone other than the Dev (or Dev team) owning the code, executed with elevated rights or not. Just my take on it.
Fair enough, we'll have to see what others chime in with and see if that's a general consensus.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 27, 2011 at 5:55 pm
DBA's rarely own code, and developers don't often have admin level access to production. Developers have responsibilities to maintain the code, DBAs have responsibilities to safeguard the databases as a whole. DBAs may develop code that may or may not go back through development. I have been on both sides and sometimes straddling this fence. But in the end development should be consulting with the DBAs on upcoming deployments and anytime a new technology is used, such as CLR or service broker. The first time a DBA hears about them should not be when they are already broken or as they are being deployed.
So short answer, in general the dev group owns the code..
CEWII
June 27, 2011 at 9:23 pm
Gosh... good questions, Craig.
If we can, in fact, put aside the idea that Developers frequently have no readability on a production database or server, here's my "It Depends" answer. 😉
The Developers own the code 100% right up to the point where they turn it over to the DBA for promotion to production. At that point, assumes ownership of the code and has (or should have) the right to turn back any code that doesn't meet company standards and certainly any code which is classified as "dangerous" to either the data or the server. An example of "dangerous to the server" would be something like using a Triangular Join to do a running total on a million rows or a joined UPDATE without the target table being in the FROM clause. An example of "dangerous" to the data would be something incredibly obvious such as an UPDATE or DELETE with insufficient criteria. The DBA will not be able to site dangers such as totally inappropriate logic which is contrary to a business rule because the DBA will not have the knowledge to make such a decision.
If the DBA finds no reason to turn the codeback, then the code becomes the property of the DBA. No one is authorized to change it except through proper channels and the DBA must guard against unauthorized changes because of things like SOX compliance, SEC audits, and a healthy dose of common sense.
The same goes for data. Once it enters the realm of production, the DBA owns the data and must guard it. The data may only be added to, modified, deleted, or even selected through proper channels only. A proper channel may certainly be through an app or through an approved stored procedure. Developers making direct changes is not a proper channel. Developers submitting tested/approved code to the DBA to make data changes is a proper channel. Again, since the DBA owns the code and the data in the server, the DBA has the right to refuse a "dangerous" data "upgrade" or "correction".
That's the long story. The short story is (IMHO), that once something is turned over to the DBA, the DBA owns it lock, stock, and barrel. The DBA doesn't need to necessarily understand the business rules behind the code to own it any more than (s)he needs to know which new entries were made in the data to own the data.
I guess you could also say it's a huge matter of semantics. To me, ownership means the person responsible for protecting it. Ownership, in this case, doesn't mean being responsible for it satisfying the business rules that it's supposed to. The previous owners (Developers) are responsible for that and that's likely a hint to the real key to all of this. 😉 It's a shared ownership. Functionality is owned by the Developers... but they can't change the code the DBA owns. They have to submit the changes to the DBA who will "disown" the old code and become the new owner of the new code.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 48 total)
You must be logged in to reply to this topic. Login to reply