October 31, 2016 at 12:33 pm
Bill Talada (10/31/2016)
On a project team a DBA just one member. My DBA responsibilities are negotiated at the beginning of the project. I'll match my rights and controls with the responsibilities and inform everyone what they can expect. Some nhibernate projects just want me to push structure changes to other environments. Some fat client projects want me to control everything. In other words, it is all just work and I don't care as long as a non-changing agreement is reached.The biggest benefit of having a DBA is that they are system focused and design according to that. All requests from developers appear to be quirky and optimized from their "self-ish" point of view. By taking a system viewpoint we can standardize and optimize better. In the long run developers will appreciate a more stable and easier-to-learn system.
I apologize, but I can't get behind the "DBAs are system focused" and "developers are self-ish" point of view. I've worked with people across the broad spectrum. More than a few DBAs have been extremely myopic and blindered, including myself at times. More than a few developers have had a broader understanding of what were doing and the best way to get it all done in a cooperative, agile, yet using well-understood and well-communicated methods that included adequate up-front design.
We all have to aim for the same things and this "we're good and they're bad" is a big part of what leads to "they're bad and we're good" on the others side of the imaginary wall. The thing is, there is no wall. We are responsible, in part, for development and developers are responsible, in part, for operations. In order to do this, we have to toss the emotional baggage and be flexible in our approach.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 31, 2016 at 1:00 pm
I don't think I implied developers are bad. I work with lots of brilliant developer guys whom I look up to. People have a view on the world strongly dependent on their environment and duties. Developers live inside Visual Studio and think of the database as a thingy that persists objects in an impedance-mismatch table format. Hopefully a DBA will have a strongly different view of the world as in principles of normal forms, security, performance, and data patterns. Of course the more experienced a DBA the more quality he will bring. Both developers and DBAs put in minimal care into time sheets and administrative tasks that are the main focus of project leaders.
I guess my previous post was really a statement that developers are often asking me to take a denormalized shortcut for them but they don't realize the impact to other developers in the long run or the complexity they are adding to the poor reporting guys. Perhaps there are cases where senior developers may be more competent than new DBAs in a DBA role.
October 31, 2016 at 10:56 pm
Bill Talada (10/31/2016)
I don't think I implied developers are bad. I work with lots of brilliant developer guys whom I look up to. People have a view on the world strongly dependent on their environment and duties. Developers live inside Visual Studio and think of the database as a thingy that persists objects in an impedance-mismatch table format. Hopefully a DBA will have a strongly different view of the world as in principles of normal forms, security, performance, and data patterns. Of course the more experienced a DBA the more quality he will bring. Both developers and DBAs put in minimal care into time sheets and administrative tasks that are the main focus of project leaders.I guess my previous post was really a statement that developers are often asking me to take a denormalized shortcut for them but they don't realize the impact to other developers in the long run or the complexity they are adding to the poor reporting guys. Perhaps there are cases where senior developers may be more competent than new DBAs in a DBA role.
I understood what you meant there from a systematic approach versus linear approach. Here is a good reference I think relates.
We often had people assigned specifically to system building. One of the common misconceptions is that systems are designed in silos. In fact, they are designed to cultivate and support each other. For example, if you change one system, you have to address all other systems and how those changes impact everything else.
In some cases, developers take a very linear approach to their objectives. It's not for every case, but more often then not, a systematic approach to design is not always in the cards. ORM for example is not exactly good for that system design. It's good for the siloed developer who needs to get stuff done. Thus, you are forced to adapt the system to support the developer the best you can.
When you're thinking about systems, the more control you can have over what's coming into the system the better. That does not mean a new piece of technology can't come around that makes what coming in more dynamic and self-sustaining. In that case, there is business value because you are likely reducing the overhead of having to support what's coming in. If there is great business value there (i.e.: reduction of overhead the results in reduction in hours, resources, etc), then you owe it to not just yourself, but to the business in order to make a business case for the new piece of technology that will increase that value of if that value makes sense to the business.
I spoke on similar in previous threads a week back. Sometimes it's not easy making that happen, especially if that results in teams maybe only looking out for themselves and or married to existing tech where it's hard to move them towards new tech due to the obvious. Regardless, putting emotions aside and pushing the business as well the (or other) team forward is often the best approach for sure.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply