DBA's vs Developers
-
I have been lucky in my training path as well to be mentored by someone who trained themselves into a DBA position.
I worked for several years with him (I cam from an Access background). I now know the right/wrong things from my/his trial and error.
I can tell that where I currently work there is 0% interaction with myself (DBA) and development. This is due to the environment we are in. I maintain/develop code that is in production and they work in R&D. I have to make due with not allowing code into production if it doesn't meet standard.
Overall though I think that most shops have a person that is DBA/developer and then developers
AJ Ahrens
SQL DBA
Revenue Assurance Management - AT&T
Good Hunting!AJ Ahrens
webmaster@kritter.net -
test
-
I think alot depends on the size of your organisation and the culture.
In a small to medium organisation it is possible to get to know most of the developers. In a large organisation then the best you can hope for is to know the team leaders.
As a DBA I make the effort to speak with as many development people as I can. In effect I am marketing my skills and services.
I've reached the dubious position of having more people asking me questions than I can possibly answer.
If a developer does not know who you are or that your position exists then they cannot refer to you can they?
You cannot sit in splendid isolation and make pronouncements on database usage. You have got to be prepared to go out there and enforce them and win the backing of your management to do so.
A DBA role IS a management role after all.
-
Not that I disagree with much said in this thread. Quite the contrary: It all rings too true. We're all familiar with those cases where hot-dog programmers concocted the database from Hell, and where management wants everything tomorrow instead of right.
But here's a perspective which has received little attention: What about those cases where management is captured by a cabal of academics, and the resulting database design is a hyperkluge of stultifying perfection on paper, but a gravity-bound, inert behemoth in real life?
Before you break out the can of flames and start spraying me like I'm an ill-mannered cockroach, no, I'm not talking about a reasonably normalized database. I'm talking about the sort of monstrosity you usually see in government, especially military, applications -- where they always skip the simple solutions and insist on skipping straight to complexity first, foremost, and always?
I spent twelve years of my career as a contractor at a large military command. One infamous database project took about six years just to go to Beta. Cost bazillions of dollars. Everything that could possibly get worked into the design, including the ancient lifestyles of Mayans and a Sanskrit/Cyrillian alphabet decoder ring, was tossed into the blender and set on "frappe". They had Ph.Ds working overtime trying to figure out how, instead of using regular configuration management techniques, they could use replication to create 500 views of the same database for users on the same backbone. They figured out how to normalize the logical components of a tinyint variable and make a separate schema for each bit.
When they finally delivered, it was like watching a circus highwire act by a pregnant elephant with a parasol and a unicycle. Splat. The very first thing management did was to fund a re-engineering so that it would work. The usual suspects, of course, were still driving, so the second verse was pretty much the same as the first.
In this profession, as in most, there are trade-offs. Seeking an arbitrary, academic level of perfection in one aspect of the job means giving up something from the other end. From experience, I can tell you that users lose patience quickly with "pie-in-the-sky" preaching. They want something they can use, like, right now. It is a good thing for database designers feel *some* heat from users, and receive *some* discipline from the budget mavens, or else they can turn database design into academic exercise -- an art form that they may appreciate, but isn't terribly useful to anyone else.
-
I've seen the military approach.
I've heard a story about NASA spending millions to develop a pen that would write in space. The Russians provided their cosmonauts with pencils.
The military analogy shows what happens when
- You isolate the design process from the end user processes.
- You don't prioritise your tasks.
- You isolate the technical solution from the business solution.
We have a CTO who has decreed that solutions should use XML. They don't care what the problem is or what the solution might be provided it uses XML. I feel like saying "The problem is that the bog is blocked" and wait for them to work it out.
-
What a great discussion...Here is my take.
At my last company (around 100 IS staff), the DA (Data Architect), DBA and developer duties
were done by sperate groups. This was good because the databases were locked down from
changes without someone else looking at the changes. This was also bad because getting
a small change (even a small data change) involved writing the script and allowing the
DBA's to run the script.
My current company (around 6 IS staff) has things a lot looser. The developers are doing
some of the database design with guidance from the developer with the most knowledge of
database design. It would be nice to have a full-time DBA.
The best developers are the ones who know how to successfully design a database with
some guidance and the best DBA's are the ones, who you can go to with that sticky coding
question you can't quite figure out. It all boils down to the fact that people need to
decide to get along and back each other up. When this happens, it makes work a very
fun place to be.....
Anton
-
Does anyone here work in a shop that's implementing ADO.NET? I bring this up b/c I'm both DBA and a developer, although I don't get much time to DBA these days. Anyway, developers can't use the CommandBuilder object if their SQL involves more than one table. So the solution, if there's a time crunch is ALWAYS, add another field to the table and to h3ll with normalization. This creates field creep, the database equivalent of using a Goto statement (once someone uses one, they start using it all over the place). Anyway, ADO.NET is great and all in many regards, but trust me on this, all of the below mentioned problems get much worse if the developers are new to .NET and even worse if they don't like changing the way things are done.
There's another problem I've discovered.... Since I develop PDA applications primarily, we're using SQL CE. Well, big flat tables with a bunch of empty fields that were created to facilitate 'getting the app out in a timely manner', replicated over to a PDA can consume a buttload of resources---to the point it's prohibitive in many regards.
What's my point? Well, the old days of Developer/DBA rivalry are going to come to an abrupt end if .NET continues to advance in the market place. I've seen that every 'compromise' made to get a product out causes a lot of problems every time it's tried. But on the same hand, stuff needs to get developed before the customer buys someone else's stuff. And I can tell you with absolute certainty, that everything is a trade off now. And many short cuts or corner cuttings can cause such big problems down the road that everyone needs to discuss what's going on AND HOW IT WILL AFFECT THINGS NEXT WEEK vs Tomorrow. I honestly can't see how any company is going to be able to embrace .NET and the Compact Framework in particular, without a whole lot of people brainstorming and thinking about the ripple affects of damn near everything they do. I think this was always the case, but it was easy enough to brush under the rug. But I can assure you, it's a whole lot easier adding a bigger hard drive, more ram etc to my Dell server than it ever will be to do the same on a PDA. Same goes for laptops and Tablets although not to the same degree.
And why do I think this will actually happen? Because PDA and Tablet PC apps are sexy and sales people love them. And customers are going to start demanding them. And they are the marketing department's dream come true. And after stuff is deployed, and middle mgt realizes that performance problems can't be fixed by adding an index or getting more RAM and people have to deal with upset customers, this problem is going to wither on the vine.
But that ain't for a few years for most folks.
-
Age old problem, age old solution.
There is never time to do it right but there is always time to do it over!
-
quote:
I have been a DBA for over 12 years now, mostly in Oracle but Currently in SQL Server.Prior to that a developer for over 12 years.
The reason I am still a teckie is because I can!
I do not believe the question here should be DBA or Developer.
I believe the question should be experienced or inexperienced.
I would rather have a good senior developer who understands the requirements, design a database than a junior DBA who understands a Database.
I have seen wonderful systems developed long before Relational Databases even existed.
The two biggest causes of failure I have seen over 1/4 century of systems are:
1. The people involved have no idea of what it is they are developing. They know how to write programs, they just do not understand what is trying to be accomplished.
How can you develop a General Ledger system when you have no understanding of a Balance Sheet?
How can you develop an Inventory system if you do not understand where that inventory comes from?
2. No risk analysis was done.
I admit management often gets in the way. A senior DBA or Developers' salary is easy to find on the Balance. But try to find the cost of a poorly developed system, it is almost impossible.
I believe getting talented people who understand the requirements and who work well on a team are far more important than DBA or Developer.
Brian
-
Agreed on the experienced thing, though it needs to be in each area. An experienced developer may not understand relational databases and an experienced DBA may not understand how to code in C++ or some other language. You need to work together and defer to each other's strengths.
Also, you should defer to someone else's experience if you are not sure. Not that they're "right", but they've got a better chance of being so.
Steve Jones
-
I would like to add to what Steve Jones has said about experience and the whole "right" thing.
Even if you think you may have the answer it is better to ask others and research the issue and produce documentation to support your case.
I can't tell you how many times I have found code that I am working on or thinking about already done and perfected on this site. Also, having documentation allows everyone the same information and same basis to hold discussions about.
IMHO
Thanks,
AJ
AJ Ahrens
SQL DBA
Revenue Assurance Management - AT&T
Good Hunting!AJ Ahrens
webmaster@kritter.net -
I am a network admin before moving into SQL DBA. The developers here do all the design, look more like an Access DB. The director is nothing more than the developers, plus adding ton of non-sense REQUIRED columns to the table in order to keep track of changes! I wish I could play with the codes.
-
quote:
It's US, whether we are developers or DBA's. WE have to co-operate with each other.Absolutely! And cooperating means being nice.
I was a developer for about seven years; a developer/DBA for about five years; and a full-time DBA now for about seven years. One of the things that always struck me as odd was the condescension I got from a lot of DBAs when I was a mere developer. I remember going to an IDMS Users Group meeting in 1989 (anyone here remember IDMS?) and chatted with a woman from Lincoln, Nebraska, who worked as an IDMS DBA for an insurance company. When I told her I was a developer, she couldn't hide a smarmy little grin. Being young -- ok, youngER -- I rose to the bait: "Well, all developers aren't stupid." She smiled smugly and said, "I wouldn't be too sure." Physically, she was a gorgeous creature, but take a perfect "10", add two scoops of arrogance, and the result is a perfect zilch -- utterly repulsive.
That attitude doesn't seem nearly as prevalent today. Maybe that's because there are more developers with lots more experience, who would have calmly and thoroughly taken the lady to task. As I see it, software ought to be a humbling profession, not an exalting one. In how many other professions can someone be so wrong, so often, and still have a job?
But they're still out there. A couple of years ago, I had the dubious pleasure of working briefly with an Oracle consultant at a large military database shop. He certainly was bright and knowledgeable, no argument there. He would tell you so himself, just in case you might have missed it. He was also a yeller, and verbally abused those who didn't meet his high standards. One afternoon, I watched him viciously humiliate a woman, a U.S. civil servant -- i.e., his customer -- in front of her peers and other contractors like me. What she did wrong wasn't important enough for me to remember, but I remembered his behavior and have been thankful ever since that not every DBA -- not even every Oracle DBA 🙂 -- is so arrogant.
The "Love" chapter in Corinthians starts out, "Love is patient." There are other criteria, but yours truly here fails the test right off. Those of us fortunate enough to be DBAs need always to keep in mind that not everyone has our level of experience. My natural inclination is to be impatient, but I have to keep reminding myself that impatience is a mild form of hatred.
Edited by - Lee Dise on 05/15/2003 11:30:03 AM
-
Lee,
quote:
not every DBA -- not even every Oracle DBA 🙂 -- is so arrogant.It is amazing how many people think ORACLE folk are arrogant.
In general I find the most abusive and arrogant people are generally the most insecure. They have a need to belittle others just to increase their feelings of self-worth.
Abusing customers or members of staff of a customer is a suicidely bad idea. When I started project management we were told that apart from the decision makers, the stake-holders etc there were a group of people called the influencers. These people have absolutely nothing to do with your project, but they influence those who do. These people can be at all levels of the organisation. It may be a young, inexperienced employee or even the tea lady, but if they have the bosses ear then you have just gone clog dancing throught the minefield!
From my own experience being a DBA used to be a more tightly defined and specialist job, dare I suggest a geeky role? Now adays a lot of traditional DBA work has gone because the tools have improved to such an extent. A "proper" DBA is basically a super developer.
ORACLE DBA ing is still a very highly specialised role so to some extent there is still the separation and, as a consequence, the arrogance.
I have been reading about Aspergers syndrome and its symptoms describe the characteristics of an old style DBA!
-
quote:
It is amazing how many people think ORACLE folk are arrogant.I think an unquantifiable percentage of the population is probably prone to overweening arrogance, but in their day-to-day jobs may have only limited opportunity to express it. Oracle, with its arcane rules, complex architecture, and secret handshakes, provides that opportunity -- another way of saying, it's not the product's fault. It's a good product, but there's no question that understanding any of it requires an above-average intelligence. It's how vain one is about that intelligence that seems to be the decisive factor.
Also consider that Oracle's CEO is reputed to be one of the top two or three most arrogant individuals on the planet. Attitudes have a way of filtering downward.
I've spent about four years of my career as an Oracle DBA, which is another way of saying, I still had an awful lot to learn when I left it to come back to SQL Server. I always found the Oracle Help Desk people to be polite, knowledgeable, and first rate. The rank and file Oracle DBAs I worked with at TRW and AMS were a terrific bunch. We were all in it together.
But some DBAs, and especially some of the on-site Oracle reps had, shall we say, tendencies. One lady I knew, an up-from-her-bootstraps success story, was a fantastic woman in practically every respect. But when she spoke of Oracle's product, she quickly assumed an attitude of the pontificating, almost religious arrogance I'm speaking of. Another DBA, a USAF sergeant, was so in love with himself I always wondered why he didn't budget for an entourage waving palm leaves before him. (Income level seems to have nothing to do with it.)
quote:
In general I find the most abusive and arrogant people are generally the most insecure. They have a need to belittle others just to increase their feelings of self-worth.Some insecure people lash outward; others, inward. Either way, insecurity brings out the worst in people. It certainly does in me. I like the following quote, from Dr. Johnson: "Where courage is not, no other virtue can possibly surface, except by accident."
quote:
I have been reading about Aspergers syndrome and its symptoms describe the characteristics of an old style DBA!It also describes IBM mainframe system programmers back in the 1980s, a very haughty priesthood indeed!
Edited by - Lee Dise on 05/16/2003 07:32:26 AM
Viewing 15 posts - 16 through 30 (of 30 total)
You must be logged in to reply to this topic. Login to reply