December 2, 2015 at 10:10 pm
Comments posted to this topic are about the item What is DevOps?
December 3, 2015 at 12:33 am
I am seeing the same level of commitment and understanding to DevOps as I have done with Agile. It is disappointingly low. Changes in job titles. New tools. Additional responsibilities. Higher expectations. Little breakdown of silos. :crying:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 3, 2015 at 6:36 am
We have a couple people in the IT department whose duties include working closely with the Operations department. They bring to IT that perspective gained from working closely with Operations people. It's too easy for IT to just say the Operations just doesn't know how to run the software. This arrangement helps IT produce a better product. But I am not aware of anything like that from the Operations side to work better with IT. Maybe they view our current arrangement as their effort to work better with IT.
December 3, 2015 at 8:15 am
My first career was in operations and management - I was President of a manufacturing company. Then moved to designing database solutions to solve business problems ( I have a degree in computer science). So, I've worked both sides, and the problems continue. And worse, both sides often refuse to admit there is a problem.
So this continues to be a problem. The technology people focus on hard technology, often not wanting to understand how an organization really works. It is easier to just fall back on definable issues. And the people who you seek out are the super-techs. Even here at SSC.
And the business side likes to pretend they deeply understand technology - by using tech terms. Oh, those terms - like "...we need to reboot the discussion". And they love new terms. So it sounds fresh. No old technology here. So we get a new term for an old concept - like DevOps, or in the past Agile. Before agile we had Spiral.
And it continues with interviews. Tech people focus on tech questions. I've had a few where they just could not get past asking complex tech questions that can be answered easily by a simple search. Big issues are rarely addressed.
Worse, with virtually all the problems I have had to deal with, they were created from a failure of communication. Yes, the fix needed some kind of tech fix, but it could have been avoided if the solution actually matched the problem.
The more you are prepared, the less you need it.
December 3, 2015 at 11:31 am
Argh!! Steve, please stop writing articles that interest me so much. Ones that I want to respond to. Believe me, I want to respond to this, but better not.
So tomorrow, how about writing an article about taking the binary representations of a number and generating the colors red and green depending upon it's bit value? That way I can ignore the article. :hehe:
Kindest Regards, Rod Connect with me on LinkedIn.
December 3, 2015 at 1:23 pm
Rod at work (12/3/2015)
Argh!! Steve, please stop writing articles that interest me so much. Ones that I want to respond to. Believe me, I want to respond to this, but better not.So tomorrow, how about writing an article about taking the binary representations of a number and generating the colors red and green depending upon it's bit value? That way I can ignore the article. :hehe:
Traveling tomorrow, Rod, so you're off the hook.
December 3, 2015 at 1:30 pm
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.
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 3, 2015 at 3:08 pm
DevOps may be a relative new term, but the practice certainly isn't new. It's something I've done for quite a while.
Just today, the domain admin and I sat together to finish up solving a problem. He couldn't have done my part and I couldn't have done his part. We each lacked the knowledge and permissions to do the others' part. Working together, it's done now.
Edit: Oh yeah, and it didn't take 8 million emails to get it done, either. 😛
December 3, 2015 at 5:09 pm
Course, you could always bridge the gap by coming other rather than relying on a bridge.
One team. Not One (Ops), Two (Devs) and Three (DevOps) teams.
December 4, 2015 at 7:17 am
Just like there is more to SCRUM than daily stand-ups and index cards, there is also more to DevOps than just programmers with production logins.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 5, 2015 at 1:10 am
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.
December 5, 2015 at 4:58 am
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.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 9, 2015 at 5:09 am
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.
December 9, 2015 at 5:30 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.
I think that both could, and would, occur to some degree but if it is spread across the teams it might be handy to have both generalists and specialists in each team.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 9, 2015 at 8:49 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.
That's an interesting speculation, Tavis. I think it will depend in large part upon two things. First, how large an organization is and second how fixed to old ways of doing things they are. In my old job the IT shop was quite small. (We got down to just two of us when they laid me off.) We had to, out of necessity, wear a lot of hats and do lots of things. Truthfully, I miss that. Now I work for an agency that is quite large. The IT group here is about 200. With that many people its easy to specialize. That's what happens here. But I also see that its just the culture. Everyone works in their job classification and you don't work outside of it. I've heard of large organizations allowing people to cross train between disciplines, but I'm sure that won't happen here. And I can imagine even in the small environment I came from that management may have said we'll hire one developer and one system person and that's it.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply