August 18, 2009 at 10:30 am
I favor having a separate, reduced form-factor DB for the non-DBA to try out new things, leaving the implementation of the changes to the DBA once the initial kinks have been worked out of the trial DB system. (Especially when project and payroll data are involved, which includes almost all DBs.)
August 18, 2009 at 11:14 am
GSquared (8/18/2009)
The problem with treating the dev environment as an "anything goes" playground is that it can mess up other devs.
Thank you for the clarification. I knew I had to be missing something. In our group, that was the responsibility of management. Mostly, we played well together, so it never really became an issue. And even when it did, we were the Sys Admins, so we just restored the ghost image. Now days, I run local copies of SQL Server or Oracle PE.
I thought folks were mostly missing the point about this being a development box, as opposed to production. At least I can now appreciate the conversation a bit better.
August 18, 2009 at 11:22 am
rboggess (8/18/2009)
GSquared (8/18/2009)
The problem with treating the dev environment as an "anything goes" playground is that it can mess up other devs.
Thank you for the clarification. I knew I had to be missing something. In our group, that was the responsibility of management. Mostly, we played well together, so it never really became an issue. And even when it did, we were the Sys Admins, so we just restored the ghost image. Now days, I run local copies of SQL Server or Oracle PE.
I thought folks were mostly missing the point about this being a development box, as opposed to production. At least I can now appreciate the conversation a bit better.
It matters more as you get more teams, and as you get into longer-term projects.
Would seriously suck to have to "restore the ghost image", if that ended up costing someone several days or even hours of work.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 18, 2009 at 2:02 pm
GSquared (8/18/2009)Would seriously suck to have to "restore the ghost image", if that ended up costing someone several days or even hours of work.
:blush: Oh, the stories I could tell. Of course, it's a frustration you tend to bare only once (or twice if you're really dense «looking at shoes and kicking at the dust on the floor»).
Effective, though.
August 18, 2009 at 5:17 pm
I think we need to specify what type of developer we are talking about and not tar everyone with the same brush. I am foremost a database developer and yes I started on Access. This was where I learnt to use naming conventions, how to normalise data and design databases. I then expanded my experience with SQL Server and MySQL. I also develop the applications that access the databases I develop. On top of this I assist with the administration of our SQL Server boxes. I have had a few excellent mentors along the way, 2 of which I am still friends with and we now learn from each other (our career paths have diverged somewhat).
OK, enough waffle, I have my own server set up on my laptop to develop and test on so the only machine I could cripple with experiments is my own. We have a test environment (multiple servers) that is on a separate network so big mistakes cannot affect the live network. I must also say that my company trusts me to do my job properly. I do not move anything off my laptop until it is stable and nothing goes to production unless it has been thoroughly tested by people other than myself. Surely there are other database/application developers out there like myself? From the comments here it sounds like I might be in a minority!
P.S. Blandry, I think you would be a good person to work for. I enjoy reading your comments and I often re-evaluate my perceptions after reading them. Thank you.
Nicole Bowman
Nothing is forever.
August 18, 2009 at 5:27 pm
I agree with Andy Leonard, that DB Devs are required on the Dev team.
The main problem with the scenario, and with a few DBA's who are posting here, is they do not trust the developers to do anything.
2 solutions exist for this:
1 - Trust the developers to do the work
2 - Get someone from the DBA team to work with the developers to do the DB side of the work.
I'm in a small company (with regard to DB size), and i'm the sole body responsible for DBA and DB Dev. Now, we've got a consultant out at the moment doing some development which requires some DB changes. Before he started, i had 2 choices. To inspect everything that was to be deployed on completion, or do the DB work myself. I selected the second option, as i'd be able to spend a little time getting the changes structured the way I like (as ultimately they would need to satisfy me) and then providing the consultant with the stored procedure interface i'll be creating.
I understand, that in larger comapnies, people are pressed for time as it is without doing extra dev work or babysitting developers. However, it has to be realised that some devs out there are good with the DB and should be given the flexibility they require. If that's not possible because they DBA's have their head so far up.... then the DBAs should provide a body or two capable of doing the work right the first time.
And if that is out of the question also - replace the developers with people who are actually good at database development.
As for the 'lord and master' dba's who 'Dont want to be told what to do by managers', remember that your overall responsiblity is to the business, represented by management. If you can't do what they ask, then they have every right to give you the flick. If they ask for something that you know is wrong and it violates all DBA principles (like, i dunno, giving everyone permission to delete databases) and you can't make them change their mind, then you are hopeless at communicating with management and you need to find someone to interpret for you. Most managers deal with risk analysis everyday, and if you say the word 'risk' usually their ears prick up. If they want to go ahead with the stupid change, prepare for the worst, make them sign off on it and make them accountable.
I have to agree with whoever said DBAs are there to serve, not rule. If business wants something, and they can't be pursuaded otherwise, they it needs to be done. DBAs serve the business, just like any other employee. And if they don't work well with the other employees, then business doesn't get done, the business collapses and the DBA finds himself out of a job, just like all the other employees.
August 19, 2009 at 12:33 am
Excellent topic, there are too many variables in the development realm for one realistic answer. IT shops vs. software vendors, small vs. large teams, single vs. multiple products, user base size, database size...
My thought is that the thesis "Mentor vs. Protector" is a winner in terms of attracting opinion for the very reason that it is flawed. Any senior technologist should embrace both of these roles whether they be a DBA, a Network Admin, a Lead Programmer or any of the other roles that carry responsibility in delivering software products or services to internal or external clients.
Corporations depend on DBA's to keep data secure, recoverable and optimized. In a production environment that should mean that they have control commensurate to their responsibility. In the dev environment it matters more on how plentiful the development resources are, in smaller entrepreneurial shops it's imperative that the duties be shared, the pace is fast, mistakes are tolerated and everyone pitches in when there's a problem. Once there are significant clients and potential impact to the company on the line the situation changes and more structure is called for across the board. Source Control, Unit Testing, QA, Product Planning. When so much is invested in the creation of the software solution then DBA's and DA's should be the keepers of the schema and provide tools and processes to facilitate the companies development pace.
Much of what has been discussed in this topic is the misuse of authority, information hoarding, access hoarding and in more blunt terms simple bullying. These patterns are hardly specific to DBA's, anyone in a position of power is susceptible and the solution (management do not tolerate those who do not serve the best interests of the company) has already been well addressed here.
So, hire good people, model appropriate behaviour and let the DBA create the stored procs and indices while the developers implement efficient objects, maps and lists and select the correct UI controls. Let the experts do their job and ensure that they have respect for one anothers responsibilities.
August 19, 2009 at 1:08 am
Silverfox (8/18/2009)
I think that we have met different kinds of management over the years with all due respect
Now there I can agree. For all the rights and wrongs of DBA conduct we seem to be discussing here, there's definitely a parallel discussion that could go on regarding managers; good, bad, effective and ineffectual - the whole spectrum.
Semper in excretia, suus solum profundum variat
August 19, 2009 at 1:16 am
As for the 'lord and master' dba's who 'Dont want to be told what to do by managers', remember that your overall responsiblity is to the business, represented by management. If you can't do what they ask, then they have every right to give you the flick. If they ask for something that you know is wrong and it violates all DBA principles (like, i dunno, giving everyone permission to delete databases) and you can't make them change their mind, then you are hopeless at communicating with management and you need to find someone to interpret for you. Most managers deal with risk analysis everyday, and if you say the word 'risk' usually their ears prick up. If they want to go ahead with the stupid change, prepare for the worst, make them sign off on it and make them accountable.
I have to agree with whoever said DBAs are there to serve, not rule. If business wants something, and they can't be pursuaded otherwise, they it needs to be done. DBAs serve the business, just like any other employee. And if they don't work well with the other employees, then business doesn't get done, the business collapses and the DBA finds himself out of a job, just like all the other employees.
As one of the DBA's who was probably mentioned by that quote, I would like to clarify it a bit more. Some of the managers I have had in the past, have had no technical understanding of what we do. and have risked company security by allowing developers to have elevated rights on servers, purely because developers have said that they need it to complete their project on time. I have worked at companies where developers have asked for and got from management sysadmin on production servers, even though dba team has illustrated the risk.
I have been a database developer for over 10 years, then Developer/DBA then DBA. So I understand all facets of this topic. I have always been a strong believer in allowing developers the rights that they need to do their job on development servers. The only thing I stand firm on, where I can, is controlling access to the production environment. What happens on the development environment is up to the developers, and if they need assistance, which in my experience, they dont, they prefer to solve it themselves, I am there to assist if necessary.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 19, 2009 at 1:20 am
dtinney (8/19/2009)
...Much of what has been discussed in this topic is the misuse of authority, information hoarding, access hoarding and in more blunt terms simple bullying. These patterns are hardly specific to DBA's, anyone in a position of power is susceptible and the solution (management do not tolerate those who do not serve the best interests of the company) has already been well addressed here.So, hire good people, model appropriate behaviour and let the DBA create the stored procs and indices while the developers implement efficient objects, maps and lists and select the correct UI controls. Let the experts do their job and ensure that they have respect for one anothers responsibilities.
Great summary, and this your first post, I believe. What an entrance..... 😎
Semper in excretia, suus solum profundum variat
August 19, 2009 at 6:27 am
Silverfox (8/18/2009)
edill (8/18/2009)
First of all, I am more of a developer than a DBA and while I understand and can work with SQL Server fairly well, I would never claim to have the level of skills that a full DBA would have.What more would the DBA's here like their developers to do?
whoah, How long have you got, maybe If i can find a developer who can send me a script that actually parses, that would be great improvement, or even if they bother to test it before they give it to me, that would be fantastic.
re-runable scripts, that is the biggest bug bear that i have, regarding scripts from developers. I should be able to run a script multiple times, repeatly if i want to, without harming either the schema or data. so the script must have a use [database], object creation checks and be able to undo data changes. that isnt much to ask, and I do appreciate it 😀
Anything else and I think I am pushing my luck some what 😛
Looks like I failed to mention the fact that my detailed notes generally include the scripts that I ran on the database, generally as an attached USB drive where allowed.
Eric
August 20, 2009 at 8:26 am
Silverfox - I don't know where your developers are trained then!
Almost all the developers that I have had the pleasure of working with throughout the years have had TSQL programming skills as well as language programming skills to produce good working processes. After all TSQL is just another language, and the inherent methodical skills and approach required to develop, say VB or C# coding are readily transferable to the TSQL environment. Now I know 'died in the wool' DBA's will not be happy with this assertation, but DBA's and Developers can and must work togther where a reliable and efficient system is required.
BR DaveT
BR DaveT
August 20, 2009 at 8:30 am
davtt (8/20/2009)
Silverfox - I don't know where your developers are trained then!Almost all the developers that I have had the pleasure of working with throughout the years have had TSQL programming skills as well as language programming skills to produce good working processes. After all TSQL is just another language, and the inherent methodical skills and approach required to develop, say VB or C# coding are readily transferable to the TSQL environment. Now I know 'died in the wool' DBA's will not be happy with this assertation, but DBA's and Developers can and must work togther where a reliable and efficient system is required.
BR DaveT
I consider myself a "died in the wool DBA", and I've worked with devs who were good at T-SQL and devs who were rotten at it. In most cases, the ones who were rotten at it, weren't exactly stellar at C# or VB or anything else. I know one exception, and his SQL excentricities are easy enough to bypass by building his procs for him, while he builds excellent C# solutions.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 20, 2009 at 9:41 am
Fair Comment!
What you say is that a good developer will normally be an OK TSQL programmer. That is sort of what I mean. I would agree that some developers will develop a pile, but that is why we Consultants have a job I suppose.:-)
BR DaveT
BR DaveT
August 20, 2009 at 1:11 pm
davtt (8/20/2009)
Fair Comment!What you say is that a good developer will normally be an OK TSQL programmer. That is sort of what I mean. I would agree that some developers will develop a pile, but that is why we Consultants have a job I suppose.:-)
BR DaveT
It mainly depends on whether they can wrap their heads around objects and methods for .NET/Java/etc., and around sets for SQL. It takes two different approaches. If they can do both, they'll do fine. If not, they'll do one or the other poorly.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 15 posts - 31 through 44 (of 44 total)
You must be logged in to reply to this topic. Login to reply