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 intendedSo 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!!!