Developers vs. DBAs

  • Comments posted to this topic are about the item Developers vs. DBAs

  • Thanks Jim, a worthy subject, although somewhat simplified. Often it tends to be not only two sides but four or five, including database developers, business analysts and solution-, database- and systems- architects as the spanners in the works.

    In my experience, it doesn't take a huge effort to even out the differences but it's still an effort.

    😎

  • the problem is that the two are fundementally at odds - DBA promote stability and reliability , developers promote "Constructive destabilisaton"

  • geoffrey.sturdy (6/12/2014)


    the problem is that the two are fundementally at odds - DBA promote stability and reliability , developers promote "Constructive destabilisaton"

    ...and that isn't going to cause offense by using a huge generalisation that promotes one side whilst knocking the other. Grandiose words hide nothing.

    What was it you said? Flame on?

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended

  • In my opinion the problems lies in the following often being the case:

      1) Management using one team as a leverage against the other (usually in both directions)
      2) A lack of understanding of the issues facing the other team (again in both directions)
      3) No scope allowed to cater for the other team (often management favours one team but which one varies)
      4) Poor skills (if someone isn't good at their own job then don't expect them to even try to understand yours - also applicable to both)
      5) Job protection (same for all)

    The problem lies in that we often work in environments where competition for resources is fierce so we would be naive to think that it doesn't permeate throughout. Better organisations try to avoid this by attempting to make all internal competition fair and based on the underlying principle that what is selected should be what is best for the organisation overall (including all its stakeholders).

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • geoffrey.sturdy (6/12/2014)


    No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended

    So any roll out of changes by developers "by their nature de-stabilise a system".

    But any roll out of changes DBAs "promote stability and reliability".

    How on earth can that be anything but a generalisation that causes divides between two parties?

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Personally, I think the blame lies mostly with the DBAs. Ten to Fifteen years ago, when all the modern development paradigms were starting to shake out, when object oriented programming was really getting to its feet, DBAs acted like a bunch of over-protective jerks. Yeah, we had reason to be. You want to ensure that the database is online, accurate, and, if possible, fast. So we stood in the way of developers and tried to dictate what they do, slowed them down, threw up road blocks. But the developers still needed to respond to the business and move things fast. So, they bypassed us at every opportunity.

    Now, I sit in developers conferences, because I try to go to those to present, as a DBA, and listen to how we're no longer needed, dinosaurs on our way out, etc. But, I hear how they hit problems with their tools, aren't sure how to solve some of them, are concerned about downtime, etc. In short, all stuff DBAs could contribute to if we could get re-invited to the table.

    At this point, both sides are to blame for not recognizing that it's not code or data that's important, it's the business.

    "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

  • Change your releases so that the developer and DBA relationship can be improved with non-functional releases. The business users that quite often drive the I.T. department need educating on the technical aspects of running systems. Having technical releases allow for database patches to be formalised and code optimisations to be written. Over time these formal technical releases educate the parties as to each others role. They need to be formal, described and discussed so the business user, developer and DBA are educated by them.

  • A quick (and slightly biased) question: I am a developer whose only community that I am active on is this, so how many of you DBAs are active on developer forums?

    NOTE: This is not supposed to be a loaded gun sort of a question even though it could be read that way. I know many developers who get by with as little knowledge (often incorrect) as they can about the RDBMSes that they deal with. They shouldn't. They should be places like here. This question is asking the DBAs out there whether they behave more like Grant, for example, or not. (Pointless asking developers here the same question because, well, they are here :smooooth:)

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I do both development and DBA activities, so I get to design it end-to-end. I don't have the conflict of developer versus DBA, as I pick the best tool for the job, and that tool is never an ORM because of the uber-inefficient code they produce.

    I find the most conflict occurs when determining user requirements. The business side doesn't know what they want because the client doesn't know what they want. So, naturally, they want me to write something. Then they change it 45 times until they like it. Now it's in production and everyone's happy, up to the point where they want it to do something in a different way that was never even thought of. This continues in perpetuity for several years and then there's a large meeting of the minds where the business side actually takes the time to sit down and really think things through. Then a redesign happens with lots of hours (and therefore cost) being sunk into something. Voila! It now does exactly what everyone wants.

    I think the trick is to get people to think it through before design starts. Everyone's in such a rush that they don't want to take the time to think it through the first time, but it sure does save a pile of time and money when it happens.

  • Gary Varga (6/12/2014)


    geoffrey.sturdy (6/12/2014)


    No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended

    So any roll out of changes by developers "by their nature de-stabilise a system".

    But any roll out of changes DBAs "promote stability and reliability".

    How on earth can that be anything but a generalisation that causes divides between two parties?

    Increase in Change = Decrease in Stability is I think Geoffrey's point -- not that it is a ding against developers. In this case the DBA's when compared to the Dev's are like IT to the Business. The Business needs to change constantly and so development happens (with or without IT involvement; see Shadow IT). But IT is incentivized to keep the lights on and the trains running. Any change must be slow or it will be de-stabilizing and thus likely to hurt your up-time stats.

  • Tension arise when Developer and DBA roles/responsibilities are not properly separated.

    If the company divides its employees into Developers and DBAs, it should also clearly separate their roles and responsibilities so there is no overlap.

    - Developers design and implement applications.

    - DBAs design and implement databases.

    What this means in practise is that every database should have a well-defined stored procedure interface, and applications should use the stored procedures and should not directly access the tables within the database, either using Entity Framework or any other means.

    When a new requirement comes along, the Developers and DBAs should get together and agree what database interface is required. The Developers can then go away and write the application code while the DBAs can go away and write the database stored procedures and if necessary extend or modify the database schema.

    With this approach, Developers retain full control over the application design and DBAs retain full control over the database design, and both camps are happy.

    It sounds simple because it is. Problems only arise when people forget the basic principles of software engineering, i.e. every component must have a well-defined interface, and users of a component must not bypass the interface or make any assumptions about how the component works internally.

  • A little bit off topic there from Ed Wagner as requirements gathering is a can of worms best left of unopened in this thread. To those who see distinct clear definitions of each role there is always overlap that causes the conflict. The key resolving the conflict is to encourage communication and understanding. We manage these relationships despite the management rather because of them.

  • scott mcnitt (6/12/2014)


    Gary Varga (6/12/2014)


    geoffrey.sturdy (6/12/2014)


    No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended

    So any roll out of changes by developers "by their nature de-stabilise a system".

    But any roll out of changes DBAs "promote stability and reliability".

    How on earth can that be anything but a generalisation that causes divides between two parties?

    Increase in Change = Decrease in Stability is I think Geoffrey's point -- not that it is a ding against developers. In this case the DBA's when compared to the Dev's are like IT to the Business. The Business needs to change constantly and so development happens (with or without IT involvement; see Shadow IT). But IT is incentivized to keep the lights on and the trains running. Any change must be slow or it will be de-stabilizing and thus likely to hurt your up-time stats.

    My point is that, bearing in mind the editorial, the whole way of thinking is as flawed as the value of the number of legs as described in Animal Farm (the George Orwell book for those who are aware of other less literary references that can be attributed to). And no I am not calling DBAs pigs 😉

    Categorizing all tasks that development do as destabilising changes (i.e. deployment of new code which WILL destabilise the system) ignores the other tasks that development does. It also ignores the sea of change in software development towards a more dynamic, yet engineered, approach. If people aren't seeing this then either they are not opening their eyes or they need to nudge their colleagues to open their eyes to a little self improvement (of course, management need to invest to gain these benefits).

    Categorizing all tasks that DBAs do as stabilising changes ignores that sometimes DBAs deploy code in the form of stored procedures, deploy code in the form of CUs and SPs and assumes that all other tasks are always carried out and never reduce the stability of systems.

    Talk like this is certainly fence building.

    So in answer to the editorial, the attitude that everything that developers do is detrimental to stability of systems whereas everything that DBAs do stabilises them is one that appears to be accepted by some and perpetuates a perception that DBAs consider themselves god like when compared to the mere mortals in development who muck things up and creates a less collaborative "us and them" environment.

    Excerpt from a sketch from BBC's "Miranda":

    Stevie: "No offence but you're not much of a looker"

    Miranda: "You know it doesn't make it any less offensive starting with 'No offence but...'"

    Edit: Corrected grammar in sketch quote.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 1 through 15 (of 79 total)

You must be logged in to reply to this topic. Login to reply