April 2, 2003 at 7:51 am
After following the SQL vs Oracle thread and having read related topics at other times, I have a general question: how much teamwork actually goes on between development staff and DBA's? One of the posters -- Rob4441 --stated something along the lines of the people involved having more impact than the choice of database. I get the sense from my readings that most of the time each role works very much in isolation with little contact, and sometimes the relationship can even be adversarial to a certain degree.
Is this due to a lack of in-house standards when it comes to SQL development? Politics? Personalities? Lack of training? Laziness? Other business pressures (tight deadlines, etc.)?
Or is this a non-issue and am I all wet?
Vik
April 2, 2003 at 8:03 am
I guess it's down to how each the development manager oversees the interaction between Application development and the DBA role. Where I work it's nice and clear. Mainly because I do development as well as the DBA role.
We have rules in place to ensure that the other developers and the dba must interact. Here it is pretty much a team effort.
The good thing is that they are quite knowledgable when it comes to creating SP's and they approach me if they do have any issues...which I encorage...I'd rather be asked a question (no matter how dumb) that them get themselves in a muddle.
Clive Strong
April 2, 2003 at 8:38 am
I agree its mgmt that makes the difference. Right now I wear two hats, DBA and developer, so it's become easier to make sure I do things I agree with!
Andy
April 2, 2003 at 9:37 am
LMAO.......Andy is also a good comedian........
From what I've seen, it comes down to management, as stated. The main issues I've seen in this area boils down to the development guys being given unreal time lines, so have to cut corners to make the deadline. This creates issues in supporting the database generally, as the corners cut are usually not benefitial to the production guys. resentment can build up, and communication break down, etc...
Just one scenario I've seen personally.
April 7, 2003 at 8:22 pm
I work for a utility billing software company. We developed a CIS system from scratch starting in 1998. We didn't even hire a DBA until 2000. Although are CIO is savvy in SQL Server, when I was a developer I had little access to him. He created some very minimal standards and the developers where cut loose. We pay for this today. For one client, we process thousands of records everynight (bills, payments, etc...) and we see tons of deadlocks, timeouts and slow performance because developers just didn't know any better. They knew the basic select query and that's about it! So I think that's mostly management's failure to notice that gap as well as the CIO not controlling the quality of the data and stored procedures.
Darren
Darren
April 8, 2003 at 3:32 am
I wear many hats myself and have so far been lucky enough to be both the Developer and DBA, but I have a good background in SQL and am constantly reevaluating code choices and process to streamline. However, I will be getting involved with developement in an Apartment server situation where there is a DBA I will have to deal with. Of the minor situations in the past where I owned data until a group found a permanent home I am concerned with this project. The problem I previously had was the data base was fully scripted by the vendor and the data was made available to the DBA to handle the process. I got the call the next day saying I was going to have to do the move. At that point I was hoping mad as he was paid to handle this and I was in effect doing his job. Now with the apartment server (and for those who don't know, this is a multiple database server used by more than one group) I will of course e required to let them see my SQL code to test and then implement, but about all over there couldn't write good code if it was spoon-feed to them. I am just going to hate dealing with them and am looking for a way out of it. What a headache.
April 8, 2003 at 7:28 am
I have been a developer and a DBA. I had the advantage of mentoring with a DBA while I learned the process.
I depends on the DBA and how available he or she is. I have been in several companies and I have been asked to "fix" several messed-up databases. Developers are always in the process of learning something new and it is usually not how to build a database. It usually takes some meetings and one-on-one conversations to establish the relationship. Once that is in place...
Patrick Birch
Quand on parle du loup, on en voit la queue
April 8, 2003 at 8:25 am
Interesting...
To quote dgermundson:
"He created some very minimal standards and the developers where cut loose. We pay for this today."
I think this is the biggest problem in development shops, bar none, and it applies to everything they do, not only database design. Developers with little or no guidance regarding standards or management, and everything follows after this: next to zero maintainability, buggy software, poor documentation, and pi**ed off users.
It's completely management's responsibility to keep a tight rein on developers (almost literally, sometimes). And usually the worst culprits are managers who were promoted from the ranks of developers (with one exception, but more on that later). They tend to focus more on tools, technologies, and the Next Interesting Thing rather than on the task at hand and making sure the software they build today will meet user requirements and work properly.
And the one exception to this? Managers who are ex-developers, but whose development jobs involved cleaning up some other shmuck's crap. They know better, if they aren't too embittered by the whole experience to turn into the Manager From Hell.
Whoops, getting a little hot under the collar. That's right, I've spent a lot of time cleaning up other people's messes...
Vik
April 24, 2003 at 8:08 am
Yep, seen a lot of this sort of thing. Comes down to a single issue: Managers who are ignorant of the development process let developers who know nothing about databases design them.
Management (and let's face it, most managers in IT who hold purse strings are failed developers who got promoted so that they could not do any damage) simply do not understand that the design of a database is fundamental to developing good code on top of it.
Lesson 1 : If the database design is rubbish, the code will be too. Do not kid yourself that it is any other way.
This is not rocket science.
If code has to be written to cope with a badly designed database, the complexity and therfore the reliability of the application will reflect that. Keep it simple.
Lesson 2 : BAD CODE COSTS YOU MONEY. AND BAD DATABASES MEAN BAD CODE.
THEREFORE (think carefully about this) : BAD DATABASES COST YOU MONEY.
Think of it as analogous to building a house. Databases are the foundations. Code is the walls. User interface is the extra fittings. If your plans are junk and your foundations are built by a two year old with a bucket and spade, then no matter how much you spend on the marble walls and gold plated taps, the thing is going to crack and fall apart soon after you've put the roof on and your client has started living in it. Same with an app. that has shoddy foundations.
You will pick up the repair bill.
It WILL add to your budget.
And your bonus reflects your budget, doesn't it ?
Did someone stir in the back row when I mentioned that?
In a quality organisation, managers understand this. The DBA should be involved at every stage of the development process, providing valuable input from start to end, whether on the database design, the database server hardware configuration, the writing of efficient stored procs, or the creation and maintenance of indexes.
Lesson 3 : Accept that pure developers know little about databases. Hire someone who does.
If you get your database right and control what your developers can do to it, then you spend more time being productive and less time doing costly troubleshooting of long running cursor based queries and re-writing diabolical SQL written by a "Junior" Developer/DBA (ie : 99% of the time just a Developer). Until most management bite the bullet and accept that paying a few thousand a year more for a decent DBA who has done development in the past is FAR more cost effective that doing it on the cheap with a Developer who can just about create a table in Enterprise Manager, 80% of IT projects will continue to be doomed. Vik, you are completely right. Only those managers who are hardened experienced techies (rather than the usual pointy-haired Scott Adams sort who play politics at their company's expense) can reign-in out of control developers, because they know when developers are giving them BS. And they know when to say 'No' to the business when they ask for unreasonable deadlines, because they know whether or not it is possible to develop what they are asking for in the time allowed.
Lesson 4 : Like politicians, the people who are your managers are those least suited and most under-qualified to do the job.
There's a *few* good ones out there, but they're like gold dust. If you get one, hang on to them. And if you are one, then the very fact that you've read this thread this far probably means that you know what you're doing.
Congratulations. And watch your back 😉
Edited by - jonreade on 04/24/2003 10:20:02 AM
Jon
April 25, 2003 at 7:03 am
Laughing.
As a DBA who has been a project manager I would say that yes, far too many projects are built on inadequate databases created by programmers.
But blaming it all on the managers is a little short-sighted. Not all managers are useless. And there is a large percentage of programmers who, mistakenly, believe that they can create databases (they have been doing so for years).
As a project manager you work with the tools that you have. If you have someone on your team who claims extensive data modeling experience you must make a decision. Project managing is politics.
Yes, the project manager should have final say about who creates the database. The project is their responsibility.
Developers are not DBAs, but they believe that they can be.
Patrick
Quand on parle du loup, on en voit la queue
April 25, 2003 at 7:55 am
I usually try to stay away from topics like this but..... Not enough intelligence. Must be a DBA (and I am)!
Just some quick thoughts. I agree that management makes a huge difference but in the environment that management does not “exist”, it is the responsibility of the DBA to make himself valuable, not by making himself a process checkpoint, but by truly adding value to the work that is being done by the development team. Several ways that can be accomplished are as follows;
-First, he needs to make himself available to the development team. Not tomorrow or later but now. Unless there is a server down they need to be able to come to you and ask a simple question (without getting there heads bitten off) and be able to get an answer.
-Second, the DBA needs to be up on his T-SQL skills. Yes, even better than the developer. Many will argue with me here but IMHO you are wrong. How can one ask for a best solution when you can't program a stored proc to save your life without using a cursor. Ouch.....
-Third, you need to be able to communicate your standards and your reasons for having them. If you are just stating standards because that is the way that it always has been, then maybe you should sit down with your developers and hear what they have to say.
-Fourth, share information with your SQL developers as if they were part of your DBA team not as a separate entity. I make a habit out of sharing every tidbit of information, article, post, that is interesting with all that I can think of that MIGHT benefit from the information. I have never had anyone tell me to stop.
-Fifth, create ways to have fun through problems or puzzles. I have found interesting posts off this site that required some cool T-SQL solutions and have used them to make a quiz / puzzle for developers and DBA's alike. It's great to see people striving to find the "best" answer to the puzzle and it provides a way to teach a technique to a developer in a fun scenario rather than making him / her change his code when there is a deadline looming.
There are more ways of making the environment conducive to growth rather than frustration but these are a few that I employ. I hope that they help someone in someway……
Thanks for listening.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
April 25, 2003 at 8:36 am
quote:
As a project manager you work with the tools that you have. If you have someone on your team who claims extensive data modeling experience you must make a decision. Project managing is politics.Yes, the project manager should have final say about who creates the database. The project is their responsibility.
Patrick,
Mostly agree with what you're saying. Some project manager's I've worked with/for are good ones, a couple I know are excellent, don't get me wrong. The problem is that they seem to be in the minority.
However, I think you've hit the heart of the problem. And that is that project managers who aren't any good do not have the basic skills to evaulate whether or not someone else has the fundamental skills required to do their job. I agree that project management is political, but I think in reality it's only partly political, and they should have proven technical abilities before they get to be in charge of a technical project. Otherwise, how can they possibly judge if one of their team is suitable for the job, or if they are just hoodwinking their boss in order to expand their CV?
I have been in the unenviable situation some years back of having an employee forced upon our team by "management" because they had to fill headcount by a certain date, and they picked the cheapest person to walk through the door, rather than the one who had the skills, despite a united technical team's protestations. The trouble is that when project management are that dim, they think they're doing their job by putting rears on seats and filling their resource quota. But if they are so lacking in skill to realise that the person they have hired is woefully inadequate, and ignore their own people who do have the technical skills to make that judgement, everyone else suffers and has to pull extra weight as a result.
To extend your tool analogy, it's like visiting a hardware store and buying a spanner because it's cheaper than the hammer you need to do the job. Sure, the spanner can be used to knock a nail in, even sounds similar if you say it quickly enough, and they both contain metal too. But if you do not know enough DIY to judge which tool you need to buy to do the job, should you really just purchase the cheapest thing you can find? If someone did that, it would make me seriously question whether or not that person should be doing DIY in the first place... and it's the same with project management. A good project manager will handle the politics, but they should also have sufficient technical ability to sniff out the blaggers and the incompetents.
OK, I am stretching a point here, yet it's the way *some* project managers actually operate.
Edited by - jonreade on 04/25/2003 08:53:25 AM
Jon
April 25, 2003 at 11:34 am
As a DBA among developers you do a lot of helping, and that's good. That's the sort of position you want. A DBA who is a speed bump in the process is rather useless.
Yes. I have been assigned useless developers. And yes, it was because management made decisions that where tossed out by the "Mythical Man-Month" back in the '70s, but those assumptions are still around. As project manager I have also fired people from my project (which is a luxury you have if you have a six-month, or a year long project - on a three or six-week project you have your team and that's it).
Another consideration is that project managers may not have the time to maintain their technical expertise - especially if they no longer pound code. I started project managing back in the late '90's and, yes, I can listen to .NET or ASP.NET code problems I really don't have the everyday coding knowledge to sit down and solve them. I have to give that to my trusted technical leads. I understand the concepts, but I just don't think in code any more.
I rely on my technical leads to tell me if the process is feasible and my DBA (since I don't have the time when I'm in project manager mode to model a database. Sadly, that usually takes longer than the time between requirement, budget, knowledge-gathering, stakeholder, and other various meetings, and writing up the notes from the meetings) to model and create the best database.
Patrick
Quand on parle du loup, on en voit la queue
May 2, 2003 at 11:52 am
We have our (VB/SQL) code peer reviewed for standards and functionality and our SQL code reviewed by our DBA for performance / good practice.
Nothing goes from Development into Test till they are both signed off. It's a great way of spreading knowledge around, and ensuring there is plenty of contact / communication between Developers and DBA.
Edited by - pdunford on 05/02/2003 11:53:50 AM
May 2, 2003 at 12:10 pm
I think DavidB made the best point. It's not Management, whether they are good or bad. It's US, whether we are developers or DBA's. WE have to co-operate with each other. The best thing to do is to sit down with the 'other side' and make it clear 'Let's help each other'. We can make each others job easier by working together. Developers write the scripts, but DBAs have to keep them running. One can't live without the other.
Rules:
1. I am here to assist you, be there to assist me.
2. I won't force you to do it my way "just because", you do the same for me.
3. Here are my standards (naming conventions, etc). What are your standards? Let's work out a compromise where our standards conflict.
4. Let's both be involved when testing is being done.
5. We both have dead-lines, we understand the pressure but let's still work together and not take it out on each other.
-SQLBill
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply