Should DBAs attend Development Meetings
-
I am searching for opinions regarding DBAs and their being allowed or invited to attend weekly development meetings. Discussed at this development meeting are upcoming and ongoing projects and their current status.
Thanks
-
It really depends on the site and the role of the DBA in the organisation. Is the DBA supporting production, development or both. If the DBA is supporting development then it's a given that they are included.
If it's a production DBA that has no involvement in development, I'd still invite them. They are most likely going to implement and support the finished products, so it'd would be beneficial that they understand where a product sits in the grand scheme of things. As a DBA is generally a jack-of-all-trades, they might even contribute to the discussion
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
--------------------
Colt 45 - the original point and click interface
-
As a developer, I make it a matter of principal to always invite the DBA to development meetings. However, perhaps it is overkill for them to be expected to attend each week.
Today's applications require tight cooperation between the DBA and development team to ensure that table structures, DTS packages, and SPs exist to support the development timeline.
Further, the DBA needs to have a decent understanding of what applications are undergoing modification or new development and how they will impact their server loading! Without that how can they be expected to plan to have adequate hardware resources available to support our applications. Waiting until rollout or even testing can result in extreme adverse impact to existing applications or development timelines!
-
Most DBA's I know only care about their precious database and how well it runs. Weather this is because they have always been excluded from the commercial side of things or they are genuinely not interested in going to these meetings I have never asked them.
However, I’m a strong believer that all stakeholder areas should have a representative at the start of a project and be kept informed of changes along the way. If the developer is not also the DBA then I think the DBA should be present.
In our company the DBA always attends the first meetings, to help him grasp the commercial side. On several occasions he has had a lot to contribute from the start of development. After that he makes his own mind up on whether to attend meetings or not. Base on the agenda he decides if he has any concerns about the project and also evaluates if it’s going to affect the database.
So, to sum up. Our DBA is give the opportunity to understand the commercial aspect from the outset and is given the opportunity to attend every meeting if he wishes.
-
I am just completing a 3 week task rescuing a bad database design on a poor performing application.
This has cost a 6 figure sum in terms of man power and the expenditure in time on the project has been astronomic.
Had I been involved (as a DBA) in the beginning half of the things that I have just implemented would have already been present. Unfortunately the other half of the things I would have implemented are not possible without significant rewriting of the application.
http://www.theregister.co.uk/content/7/34095.html
I would say that
- The DBA needs to be present at the initial meeting to get the base parameters for the project.
- The DBA needs to be present in all development meetings concerning the database.
- The DBA needs to be copied in on the minutes of the meeting.
- If a developer is going to be doing database work then this needs to be vetted by the DBA at regular intervals.
- The DBA needs to have a hand in writing the tech spec.
- If in doubt "invite" the DBA to the meeting.
-
I think its always a good idea to have your DBA involved. Why wait until the end?
Andy
-
I would always invite the DBA to development meetings. He always has the option to not appear if he doesn't feel it would be productive.
The DBA is involved once the business rules have been stabilized. He's interested in the earlier meetings but as a casual observer.
If there was something specific to the database and he was not available I would hold a meeting between the two of us to bring him up to speed.
I always valued the DBAs advice.
Dr. Peter Venkman: Generally you don't see that kind of behavior in a major appliance.
Patrick
Quand on parle du loup, on en voit la queue
-
I've been a DBA for a long time in many different shops (I used to do consulting work). In every case, I have found that the DBA, or a DBA team representative, should be involved in development discussions. The projects that worked best were the ones where the DBA was involved in application and database design reviews and code reviews.
In my current position, I must approve all data model changes, attend all architecture and design reviews, and perform all SQL code reviews. This keeps me very busy, but I'm the guy they come to when things aren't performing well.
-
Involving them early can reduce major problems late in the game.
If dev meetings have ZERO impact on Database, then make invite optional.
gaj
Gregory A Jackson MCSD, MCT
Gregory A Jackson MBA, CSM
-
Personally I would only invite a DBA if it made sense. The majority of the developers either know enough about SQL or have other developers they can use as a resource. Our environment is one that everyone is busy so why waste the time of a DBA on a regular basis? I've never felt that our development has been less than it could be by not involving a DBA in general development meetings. The DBAs are invited when we cross over the lines into areas that they support and we do not. Perhaps the roles of the DBAs here are different. Our DBAs are more geared toward managing the servers, backup schemes, database set-up... and not on development and performance enhancement.
-
If you're asking the question if the DBA should attend the developer meetings, I hope that you have seasoned developers.
Every developer team needs frequent input and assistance from someone with the DBA skillset (the title isn't relevant). This person needs no only to rescue the developer team when they've messed something up (table locking seems to be a favourite) but also has to be proactive. The odds of a team of developers using database best practises when left to their own devices are nil. The team DBA has to identify situations of complexity and has to guide the team through them. The DBA also needs to review all of the database code so that the SQL that is written is actually correct, instead of just co-incidentally returning the correct results for the test data in the development database.
My $0.02,
Steven
-
Always invite the DBA!
I can't count the number of times I had to rescue an application/datbase that was developed without the DBA's involvement.
On every project I have seen, when the DBA was involved, significantly less problems.
To me it seems pretty simple. Preventing the problems upfront will always save time and money and what Manager/Stakeholder or business person isn't in favor of that?
Ok, off my soapbox now.
Shawn
-
Thank you for all your replies. These comments have been given to the DBA Manager with hopes our DBAs are invited to future Development Meetings. All applications here utilize a SQL Server or Oracle backend and all three DBAs support Development, QA and Production environments.
-
I think the DBA should be part of the development team, even a developer with good data modeling skills may not have the current knowledge of the DBMS details.
How about when I had to explain to the application architect (senior designer type person) about identity fields. Gee they were coding calls to get the max key and add one all over the place.
The DBA, support or development, needs to understand the data model and how it is accessed. When the system is slow what is the first thing blamed. The DB !! If the DBA understands the data he can solve problems before they occur, as well as be better at solving problems when they do.
Ever had a new version dropped in and a bunch of data gets screwed up, 2 choices restore to yesterday (last week) or maybe fix the data.
I am coining a new DB modeling form, the 6th normal or abbynormal form. This is what the design looks like after the developers have fiddled with it.
Not knocking all developers, just some. We don't tell them how to code, they shouldn't tell us how to design a DB.
Though there does have to be a close working relationship, the programmers can't design the DB for them, the DBA can't design the DB for them. If either does the other suffers and the whole thing fails.
I worked on a DB design that was done by a DBA, nearly perfect IAA / 5th normal everything. Of course no one, including the designer, could figure out how to extract the data. And the selects that we could get working had 5, 6, 12 ... joins, and were difficult to read.
You gotta find a happy medium, and that takes input from both sides.
KlK, MCSE
KlK -
This seems obvious to me, but unless they're point-&-click admins, DBA's should always be invited to Dev meetings. David Poole's comment is right on the money. Take any slooow application, and dollars to donuts the db design is crap.
Signature is NULL
Accepting all invitesViewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply