April 27, 2011 at 10:54 pm
Comments posted to this topic are about the item When To Hire a DBA
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 28, 2011 at 12:38 am
Hehe I think you are right, there are dba's and there are dba's.
Some dba's does not care for what is outside of what they view as their scope while others are interested to know how a business works and how the system works together. Those who are interested in knowing more and getting a larger picture I believe often are worth more for the company and can contribute more. Those who are not interested in that I also believe have issues talking with other people and thus management gets uncomfortable and does not receive as much value as they probably expected.
People are different, some wants to learn and some are sett in their ways. I think it's dangerous not to be open minded and not to be interested both for a persons career but it also limits knowledge and growing as a person.
April 28, 2011 at 1:38 am
Ice is right, to a point.
I work for a Fund Manager (not one responsable for the current climate i might add).
The problem here is that generally speaking we arent allowd to step outside our little holes, my background is Windows Server and Network Support, Wedsite Design, TSM, Infrastructure Design, Some dev and most recently SQL. I am more then happy to help in other areas as quite often the SQL side of things is quiet (which i take as a sign that what a do isnt all that bad ;-)).
On the odd ocasion when they ask for volunteers for something, those volunteers get lumbered with repeated tasks of the same subject forever more thus putting off future volunteers. And no-matter how much i help in other areas and show how i can be of extra value the chiding is always that i (and my team) are just dba geeks and should be shund and avoided! Where did dba's get such a reputation?
Adam Zacks-------------------------------------------Be Nice, Or Leave
April 28, 2011 at 2:35 am
I have just spent close to the last three years working on a project as a dev / admin DBA.
Before we started the project, the whole team - Devs / BA's / infra / DBA's / project managers / business users, agreed that the project would be delivered in an agile manner.
This meant a lot of change initially as the organisation and most people within it were only used to taking a waterfall approach to software delivery.
I spent a lot of time working with the dev's, advising them mainly and also building the database infrastructure for each environment (DEV / TEST / UAT / PROD), as well as implementing backups and DR.
I purposely moved my desk from my little DBA corner to sit right amongst the devs.
I worked across three agile teams splitting my time between them (however, I was able to call on our wider team for support when necessary)
I have a strong dev background, and this arrangement worked well for me personally, and I know that pretty much everybody thought that it made a difference to the project.
Everything was going great, on time on budget and all the rest of it but...
the project was postponed within days of delivering it's first major output, why?
Nothing to do with software, there was a major earthquake in Chistchurch, NZ.
I am sure this project would have broke a world record (I'll tell you all more about it at some other stage) - and I am pretty eager for it to be picked up again - which will be a little while away yet.
on a brighter note - at least my DR was tested, substantially, and came through 🙂
April 28, 2011 at 6:09 am
Way back in the early 80's, especially with the advent of the XBase family of development systems, databases (or indeed, free tables) were part of the development system. You didn't have any DBA because the developer played the role of both developer and database professional. You had to know both. Granted that these databases were in the beginning simple and easy to work with, and there was no Internet, still, you needed people who were as good at database work as they were at development.
Then there came the chasm that exists to this day; one person to develop software, another, often called a DBA, to manage the databases.
I have never accepted this chasm. Even today I argue regularly that any DBA is not a DBA unless they understand code as well as database administration. It just seems absolutely ridiculous to me to have one guy closed off from one side of what software is, and another closed off in the other direction. I have seen time and again where companies, and especially management people don't understand this chasm either.
In our companies we do not hire any DBA who does not understand code and software development. Sure, these people are hard to find, but thats because to this day we still do not have any industry definition of what a DBA actually is - but how can you design software with two people in the room who don't understand each other's role very well?
To me, its simple - when we get our cars serviced, we don't see an engine expert AND an "interior specialist" - one who understands our engine, and another to advise us on new wiper blades - most would consider that absurd.
Simply put, it is LONG past time to clearly define what a DBA is, and what is expected of them for knowledge, and responsibilities. I know this because we have three DBA's throughout our organization and all of them understand software development as well as Database Administration. To me, THAT is a DBA and anything less is, well, absurd.
April 28, 2011 at 6:50 am
I am curious how you view the flip-side of that. Should "dev's" be similarly knowledgeable about dba work it truely be considered "dev's"?
April 28, 2011 at 7:00 am
Recently I found a post where a developer was struggling with a variety of problems: design, backups, and more. It was obvious this person was overwhelmed and when someone suggested hiring a consultant, this person noted their boss didn't want a DBA consultant, and wasn’t willing to hire a DBA. Management didn't feel like there was enough work to justify a full-time employee.
For many small companies or non-profit organizations, the question isn't just "Should we hire a DBA?" but rather "Should we be developing and hosting our database application in house?". Most serior level database professionals may get bored working full time in a small organization, unless that organization itself provides data or application related services. In 2011 there are 3rd party providers that host databases as well as websites, CRM application, or even remote DBA services.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 28, 2011 at 7:14 am
blandry (4/28/2011)
I have never accepted this chasm. Even today I argue regularly that any DBA is not a DBA unless they understand code as well as database administration. It just seems absolutely ridiculous to me to have one guy closed off from one side of what software is, and another closed off in the other direction. I have seen time and again where companies, and especially management people don't understand this chasm either.
Be be well rounded, a DBA should also know hardware, networking, SQL, T-SQL, ETL, and perhaps reporting tools. I'll generally draw the line at Java, ASP.NET, or more advanced BI tools. Of course in a small shop you have to wear many hats. I've worked for companies in the past where I would develop the application and database from the ground up, especially back in the xBase and Visual Basic / Access era, but that's nowhere near as common these days.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 28, 2011 at 7:19 am
I used to do a lot of development work alongside dba work before I got this job as production dba. Before I came here the dbas thought it below them to touch code, now things have changed and we are donig code reviews and helping with performance tuning. Steve, am not sure how you say that doing dev. work with dba work can land you jobs in smaller more fun companies...could you explain further? Thanks.
April 28, 2011 at 7:30 am
blandry (4/28/2011)
To me, its simple - when we get our cars serviced, we don't see an engine expert AND an "interior specialist" - one who understands our engine, and another to advise us on new wiper blades - most would consider that absurd.
No. But when the car is getting designed and built there are engine specialists, steering specialists, etc. Yes, most of them understand the whole picture and provide input but not as well as their area. Similarly, when designing an application you want to have a DBA that really understands DB design and access very, very well and understand the developer side enough to have intelligent conversations and ask questions to better understand why the developer wants the data a certain way. Same thing with the dev side. They should have enough understanding of how DBs work (and work well) so the DBA doesn't need to spend a lot of time explaining why it needs to be a certain way.
April 28, 2011 at 7:33 am
The days when projects need DB Review are long gone...would be nice if companies realized and kept data architects but a lot of them don't. in most places have developers double up to design dbs and do it the quick and easy GUI way on development atleast...Dedicated database reviewers are not DBAs they are DB Architects. Lot of DBAs know operational DBA work but are not particularly qualified to do DB Reviews.
April 28, 2011 at 7:52 am
Unfortunately, many of the reasons to hire a DBA aren't seen as necessary by many companies until they actually encounter serious problems - such as DR needs or major performance issues. The only thing that comes to mind in everyday situations is security. DBAs are there to maintain security of the databases - making sure that data is encrypted or otherwise protected, cannot be accessed by non-authorized personnel, etc.
On a side note, I am one of the "hybrids" Steve mentioned - developer turned DBA, still doing quite a bit of development work. I feel this is a distinct advantage - I can bridge the gap to find a workable solution between the developers who want to make their apps work and the DBAs who want everything to work as efficiently as possible. It also helps that I can help troubleshoot errors to determine if it's an application issue versus a database issue. Plus, as Steve alluded to, having multiple skills makes it easier to find a job that you enjoy!
April 28, 2011 at 8:12 am
junk.jjk (4/28/2011)
I am curious how you view the flip-side of that. Should "dev's" be similarly knowledgeable about dba work it truely be considered "dev's"?
🙂
I thought this article was about when to hire a DBA, not another opportunity to declare people can only be DBAs if they happen to fit the exact criteria you personally have decided upon. Accept it, there are dev DBAs and prod DBAs and different companies have different requirements from their DBA.
As to the real point of the article, hire someone when you don't have enough resources to fulfill the present and expected ongoing workload. IT's the managers job to recognise that or risk losing their current resources.
---------------------------------------------------------------------
April 28, 2011 at 8:38 am
I think this is a similiar line of dicussion to a post I addded to someone asking how to get into a DBA position. The smaller companies or even large companies with smaller sites often have no idea what they need. I worked for one such company and while I was technically doing like 5 different jobs I also got a fair bit of SQL expierence. I, like many before me, am an accidental DBA. I did not set out to become a DBA but picked up the duties somewhere along the way. The job I have now I got having never touched a MS SQL server in my life. I cut my teeth on a Unix box with sybase cursing up a storm while trying to write code in vi (UH I still have nightmares about vi). The Database was a mess and I can not imagine the state it has return to now that I am no longer with the company. They had and I would imagine continue to have no idea what it takes to keep a DB healthy and happy. It just worked and they did not care why. I was often amazed that no one even seemed to question that a report would take over an hour to generate when it should be less than a minute. Even in todays Data aware business and culture I still find that many managers hold to the beleif that it does not realy take that much effort or knowledge to be a DBA. True conversation I had with a small business owner.
Him: "What do you do for a living?"
Me: "Oh I am a DBA"
Him: "Why did you not go to college"
Dan
If only I could snap my figures and have all the correct indexes apear and the buffer clean and.... Start day dream here.
April 28, 2011 at 8:42 am
junk.jjk (4/28/2011)
I am curious how you view the flip-side of that. Should "dev's" be similarly knowledgeable about dba work it truely be considered "dev's"?
It depends on the developer. If they do a lot of work with SQL Server, even CRUD work, I would argue that they need to know more about how SQL works. Both the language and the server implementation/administration. Devs can't set up instances and then ignore backups. They can't try avoid learning about joins so they can loop and make mutliple queries to get child data. I think both need to step in the other world a bit. Not be experts, but learn to be competent, and more importantly, learn what they don't know and when to ask for help.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply