December 9, 2015 at 9:59 am
Michael L John (12/3/2015)
DevOps is what's implemented to break down the communication barriers and silos that were created when Agile was implemented.To me, it's only a new name for the things we have been doing by default for a very long time.
Me, too
December 9, 2015 at 10:23 am
Tavis Reddick (12/9/2015)
Could there be a tendency, over time and in a successful devops team, for individuals to learn new skills from the 'other' side, to the detriment of learning more advanced skills in their own professional specialisms? Either a trend that sacrifices specialism for generalism, or role fluidity that allows people to gradually migrate from developer to systems admin (say, or the reverse) by following their own preferences, rather than the needs of the group and larger organization?I suppose in a group where there were conflicts, it could go the other way, and skillsets could become more polarized and roles more rigidly demarcated.
A potential problem, but really you don't learn a lot about other environments. Developers aren't trying to be ops. They're trying to understand what requirements Ops has, what things break in deployment/operations so they can code differently to meet those needs. They may teach a little programming/scripting to Ops people to help the Ops people in their jobs.
Ops people aren't learning programming much. Just enough to be sure the things they do in setting/configuring environments are done consistently and with automation. They may teach Devs about how to configure environments or about the challenges of building jobs, monitoring, etc, but it's minor.
The idea isn't to make people duplicate others jobs. I think the idea is more to get each side to understand a little more of the other side and work closely to ensure their work integrates with the other side.
December 9, 2015 at 11:42 am
Steve Jones - SSC Editor (12/9/2015)
Tavis Reddick (12/9/2015)
Could there be a tendency, over time and in a successful devops team, for individuals to learn new skills from the 'other' side, to the detriment of learning more advanced skills in their own professional specialisms? Either a trend that sacrifices specialism for generalism, or role fluidity that allows people to gradually migrate from developer to systems admin (say, or the reverse) by following their own preferences, rather than the needs of the group and larger organization?I suppose in a group where there were conflicts, it could go the other way, and skillsets could become more polarized and roles more rigidly demarcated.
A potential problem, but really you don't learn a lot about other environments. Developers aren't trying to be ops. They're trying to understand what requirements Ops has, what things break in deployment/operations so they can code differently to meet those needs. They may teach a little programming/scripting to Ops people to help the Ops people in their jobs.
Ops people aren't learning programming much. Just enough to be sure the things they do in setting/configuring environments are done consistently and with automation. They may teach Devs about how to configure environments or about the challenges of building jobs, monitoring, etc, but it's minor.
The idea isn't to make people duplicate others jobs. I think the idea is more to get each side to understand a little more of the other side and work closely to ensure their work integrates with the other side.
Should the short definition of DevOps be "strategic partners"?
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 11, 2015 at 7:27 am
I'm convinced someone somewhere carries out an FA cup style draw every couple of years, with a pot of actions, pot of methods, and a pot of buzzwords
The results are the new Scrum, Agile, Waterfall, DevOps etc framework presented by a hip guy in jeans and jacket with an earpiece microphone charging £1000 a day "branding" workshops on how to embrace the culture of it.
The more things change, the more they stay the same.
Rant over.
December 11, 2015 at 9:20 am
Steve Jones - SSC Editor (12/9/2015)
A potential problem, but really you don't learn a lot about other environments. Developers aren't trying to be ops. They're trying to understand what requirements Ops has, what things break in deployment/operations so they can code differently to meet those needs. They may teach a little programming/scripting to Ops people to help the Ops people in their jobs.Ops people aren't learning programming much. Just enough to be sure the things they do in setting/configuring environments are done consistently and with automation. They may teach Devs about how to configure environments or about the challenges of building jobs, monitoring, etc, but it's minor.
The idea isn't to make people duplicate others jobs. I think the idea is more to get each side to understand a little more of the other side and work closely to ensure their work integrates with the other side.
This quite neatly sums up my current contract... DevOps SQL DBA. Fun times. I really must write some blog posts about the experience. 😀
Thomas Rushton
blog: https://thelonedba.wordpress.com
December 14, 2015 at 5:06 pm
Gary Varga (12/5/2015)
Terje Hermanseter (12/5/2015)
DevOps is how we built and deployed software in the 90's. Only then we didn't had a term for it. Later things changed and people started working in silos. That wasn't so fruitful, so someone found out we'd be more succesful if we worked together like in the 90's, so they came up with the term DevOps to describe how that can be arranged. Now people have to come out of their silos and start working together again, then maybe we can forget the term DevOps again.Totally valid point about collaboration, however, there is far more to DevOps than just that.
The switch between everyone working together, communicating, and sharing objectives and rigid barriers between groups ensuring that everything takes too long has happened several times - and it wasn't happening in all companies simultaneously, or even in all parts of a company simulatneously (when the company was big enough). The setup I worked in in the early 70s was very much like what is now called DevOps, but by the end of the 70s I was a senior manager in development with a firewall between me and QA, let alone me and end users.
And everything I've seen about DevOps is just stating things which I and the division I worked in thought , back in 1974, was the only sensible way of doing things.
It is a sad fact in the computer business that the wheel has to be reinvented several times; terms like DevOps, OO, Agile, and so on all describe things each of which was common practice a decade or more before the term was invented. My team was doing continuous/incremental development and deployment in the early 70s mainly because we couldn't see any other way of keeping the customers happy. A few years later (1976) another division of the same company adopted incremental development and QA, and incremental deployment to its internal systems (but not, sadly, to customers). But most people today seem to believe that incremental deployment is something very modern, and I've even seen claims that it's a concept introduced by DevOps. I wish people would recognise that inventing new jargon to describe things we've done for ages doesn't introduce any new techniques, but I don't expect it to happen - the youngsters will always assume that us ancient grey-beards can't possibly have had a clue about this stuff because they didn't, for example, call it "DevOps".
Tom
December 14, 2015 at 5:34 pm
Tavis Reddick (12/9/2015)
Could there be a tendency, over time and in a successful devops team, for individuals to learn new skills from the 'other' side, to the detriment of learning more advanced skills in their own professional specialisms? Either a trend that sacrifices specialism for generalism, or role fluidity that allows people to gradually migrate from developer to systems admin (say, or the reverse) by following their own preferences, rather than the needs of the group and larger organization?I suppose in a group where there were conflicts, it could go the other way, and skillsets could become more polarized and roles more rigidly demarcated.
If there were a trend away from the over-specialisation that exists currently in the software/computation business that would be a very good thing.
Actually I don't think that DevOps is likely to cause a trend against specialisation not only because people who like to be very specialised will still specialise but also because employers aren't going to stop asking for "at least N years experience of delivering secure high performance interactive transaction systems using SQL Server 2016" and similar requirements for narrowly specialised experience.
The opposite trend - to more specialisation of skillsets - has already caused a lot of damage: for example we have security specialists separate from database specialists separate from website specialists, and the absence of communication between the three is responsible for many disastrous breaches of data security.
Tom
December 14, 2015 at 5:36 pm
TheFault (12/11/2015)
I'm convinced someone somewhere carries out an FA cup style draw every couple of years, with a pot of actions, pot of methods, and a pot of buzzwordsThe results are the new Scrum, Agile, Waterfall, DevOps etc framework presented by a hip guy in jeans and jacket with an earpiece microphone charging £1000 a day "branding" workshops on how to embrace the culture of it.
The more things change, the more they stay the same.
Rant over.
Well said!
Tom
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply