I know what DevOps is, how it works, and what it tries to achieve - that much isn't the problem, the problem is that I fundamentally disagree with the detrimentally narrow focus of it. So great, DevOps fixed their build pipelines and allow them to do CI or whatever, wonderful, but what use is that if they haven't fixed the problem of business and dev working together to get the requirements right?
Again, you need to do some research, because you are wrong. You are narrowly constraining DevOps to be the modern scaling tools and delivery pipeline efficiencies, and while that's a part, it's only a small part. Don't feel bad, this is an extremely common misconception, and it's why most people trying to explain DevOps fall into the pattern of defining it in the negative (It isn't this, it isn't that).
Another book I'd suggest, by some of the same authors, is The DevOps Handbook. It has the exact answers that you're looking for, organizational patterns, and also examples of major enterprises that have shifted directions successfully and why it worked for them.
I tossed you the video not as an appeal to authority, but as an example of a large company that has done it, and the leader behind it doing a good job of explaining how it was successful. If you're unfamiliar, Carmax is the largest used car seller in the world (primarily US and CA market).
I don't really give a toss how quickly someone can churn shit out, I care about how quickly someone can churn quality out.
You keep making the exact arguments that DevOps provides a framework support, but yet you keep rejecting DevOps out of hand because you refuse to do some more research to better understand it. To me it sounds like your organization has adopted a lot of what is included in DevOps. If I'm wrong, and your organization is truly so special without being anything like DevOps, then you should go on a speaking and book tour and make millions as a consultancy because the vast majority of companies have not shared that success and are willing to pay for answers.
And therein lies your problem - you think that because you've always worked at organisations that have poor culture, that every company does.
You keep making hugely incorrect assumptions to fill your own inner narrative.. I've actually worked most my career in a DevOps-style model, in companies with good culture, long before DevOps was ever a defined thing.
75% of large IT projects fail (according to both Gartner and Standish) and that rate has remained largely unchanged for the last 20 years.
There is something fundamentally different about how startups work with IT than is found in large enterprises.
If you think that difference is meaningless, then I'm sorry but you're the one who isn't understanding things.
Funny you should mention 150 year old companies not getting DevOps. Lloyds is going through a transformation right now implementing DevOps (among other things) across all their delivery groups and changing the enterprise from the ground up.
They (and a bunch of other enterprises) are waking up to the fact that they need to model themselves more like startups to fight back against the disruption you are predicting. Because that disruption isn't in the future, it's now.
Read up on "BizDevOps" (which I think is a bullshit distinction, but there's a good intention behind it)
In fact, DevOps itself as I've said already doesn't even require any merging of departments
I never said anything about merging departments, that's the baggage you're bringing to the discussion. Jeff Bezos has a good principle here with the "2 pizza rule" - No team should be larger than what can be fed with 2 large pizzas. It's a good rule of thumb for optimum team size where everyone knows everyone else on the team and what exactly their responsibilities are.
it just means good cross team working, using tools to support that where possible.
Let me revise that for you. It just means good cross-functional working, using tools to support that where possible. When people are working cross-teams, then there are extra layers of abstraction between them working together. Conflicting priorities from their other teams, context-switching between projects, lack of visibility into other things in their pipelines, and the overhead of management to arbitrate between the two groups. All that goes away if you put the different skills on the same team and provide well-defined business goals for the team as a whole.
Overall, your concerns are valid, and you're a lot closer aligned to the thinking behind DevOps than you realize. I think you're simply getting hung up on the words and preconceptions about what it actually is.
Did I say that they should be both developing the app and managing the infrastructure? You made that assumption. I intentionally kept both developers and ops engineers in my phrase.
Sit them together in a common team, and they will learn from each other and deliver a better product. The biggest killer of good ideas is the pipeline where you lob hand grenades over the wall to the next team in the queue.
But I'd also agree that dev and ops guys will do a better job if they understand any budget restrictions finance are under, if they understand any efforts HR are making to improve self development and staff happiness, the strategic direction the CEO wants to take the company in, the legal requirements enforced upon the company that legal regulate, and issues sales people are facing in the field, and the challenges the corporate security team face with people doing things that unwittingly cause a potential security risk like showing sensitive data on a laptop when sat near a ground level window.
You just explained the reasoning behind DevOps.
A big principle of DevOps is that you build end-to-end cross-functional teams, and that everyone is aligned to the business goal. That means incorporating other roles across the enterprise. Put designers, security, and product on the team. It can't be simply developers and ops. Build teams focused around specific deliverable initiatives rather than throwing things over the wall between departments. It cuts out huge swaths of hierarchy slowness.
If you're on 4 scrum teams, then that's entirely stupid and undermines scrum. The teams shouldn't organized to be project-based, the teams should be organized to form a tight well-functioning, and most importantly, PRODUCTIVE group.
One of the biggest values of scrum and sprints is to reduce the amount of work in-flight at once so that each thing can be completed in a shorter timeline. If everyone is on everything, then you're wasting everyone's time on context switching.
And if there's extremely high priority work that can't wait for the normal cadence, then it should be a simple matter of the Product Owner deciding an equivalent amount of unstarted work to push out of the sprint to replace it. The point is to make the person responsible for the decision holds the responsibility for that decision.
Otherwise you end up in the classic model of "we asked for a million things at once and it's the developers' fault for not delivering"
Would you agree that the Ops guys will do a better job if they better understood what Developers were delivering? Would you agree that the Developers would write better code if they had the input and advice from experienced Ops engineers?
Of course they do but South Korea credits Trump for talks with North Korea - wouldn't they be in a little better position to know who to credit than you?
President Moon rightly figured out the the easiest way to get Trump to go along with something is to simply give him the credit.
NO ONE else knows the "company". You're arguing semantics that YOUR CUSTOMERS don't see. A brand is not an asset. A brand is the company that your customer perceives. Your customers don't see your corporate structure (which is the entire reason for corporate structures).
Do some basic research on why brands exist. Here's a hint, you didn't buy SourceForge for the proprietary technology stack.
Take the valid criticism and act on it. Stop being a dismissive jackass to your users.
To your users, SourceForge is the company. You don't get to pretend history didn't happen because it's under new ownership.
Now stop claiming "my company didn't..." as it's patently false. Instead, go out there and build up positive mindshare to try to restore the brand that was so tarnished.
My company has never bundled malware with any projects. In fact we eliminated that practice immediately after acquiring SourceForge
Wrong. Your company did. Just because you're part of the new ownership that eliminated the practice doesn't mean that it didn't happen. Earning back good reputation for a brand is a hell of a lot more difficult than earning slashdot karma.
The real vulnerability in both this and the article example is allowing 3rd party code injection. If you can't trust the source of the code, the language being used doesn't really matter. There will be ways to abuse it.
Non-transferable means that Fox can't sell the rights to someone else. Whatever business unit owns the rights can be bought and sold wholesale however without negating the licensing rights. Fox can be sold with the rights can go with Fox in the sale. Rupert Murdoch isn't the license holder, some random business unit within 21st Century Fox is the license holder.
And what about Walmart? Oh right, Wally and his family donate to Republicans and Trump is doing everything he can to attack Bezos because of a personal vendetta.
Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.
A few conveniences like performance. I changed which build servers were running part of our monolithic process recently because it took 45m to run a step in JRuby that could be done with a native Ruby gem in about 10m.
Next up, replacing that Ruby gem with a NodeJS plugin that can do it in under 2 minutes... on the same hardware.
I came in to cleanup a project built by one of those guys. 2+ decades of experience and a Java architect. It was a PHP sure where he used factory factory factories to initialize the entire codebase.... completely ignoring that in PHP you get a new thread for every request. He left when he couldnâ(TM)t figure out why the web server had to be forcibly rebooted on a 45m cronjob.
The same site also used inline static JS to set the destination of top menu items:
Itâ(TM)s important to understand how a language behaves in context, not just be able to pick up languages fast.
Slashdot Mirror
Again, you need to do some research, because you are wrong. You are narrowly constraining DevOps to be the modern scaling tools and delivery pipeline efficiencies, and while that's a part, it's only a small part. Don't feel bad, this is an extremely common misconception, and it's why most people trying to explain DevOps fall into the pattern of defining it in the negative (It isn't this, it isn't that).
Another book I'd suggest, by some of the same authors, is The DevOps Handbook. It has the exact answers that you're looking for, organizational patterns, and also examples of major enterprises that have shifted directions successfully and why it worked for them.
I tossed you the video not as an appeal to authority, but as an example of a large company that has done it, and the leader behind it doing a good job of explaining how it was successful. If you're unfamiliar, Carmax is the largest used car seller in the world (primarily US and CA market).
You keep making the exact arguments that DevOps provides a framework support, but yet you keep rejecting DevOps out of hand because you refuse to do some more research to better understand it. To me it sounds like your organization has adopted a lot of what is included in DevOps. If I'm wrong, and your organization is truly so special without being anything like DevOps, then you should go on a speaking and book tour and make millions as a consultancy because the vast majority of companies have not shared that success and are willing to pay for answers.
You keep making hugely incorrect assumptions to fill your own inner narrative.. I've actually worked most my career in a DevOps-style model, in companies with good culture, long before DevOps was ever a defined thing.
75% of large IT projects fail (according to both Gartner and Standish) and that rate has remained largely unchanged for the last 20 years.
There is something fundamentally different about how startups work with IT than is found in large enterprises.
If you think that difference is meaningless, then I'm sorry but you're the one who isn't understanding things.
Funny you should mention 150 year old companies not getting DevOps. Lloyds is going through a transformation right now implementing DevOps (among other things) across all their delivery groups and changing the enterprise from the ground up.
They (and a bunch of other enterprises) are waking up to the fact that they need to model themselves more like startups to fight back against the disruption you are predicting. Because that disruption isn't in the future, it's now.
DevOps was coined at and the community driven through Linux conferences. Not sure how you went from that to MS certifications.
Wrong. I suggest you read The Phoenix Project
Read up on "BizDevOps" (which I think is a bullshit distinction, but there's a good intention behind it)
I never said anything about merging departments, that's the baggage you're bringing to the discussion. Jeff Bezos has a good principle here with the "2 pizza rule" - No team should be larger than what can be fed with 2 large pizzas. It's a good rule of thumb for optimum team size where everyone knows everyone else on the team and what exactly their responsibilities are.
Let me revise that for you. It just means good cross-functional working, using tools to support that where possible. When people are working cross-teams, then there are extra layers of abstraction between them working together. Conflicting priorities from their other teams, context-switching between projects, lack of visibility into other things in their pipelines, and the overhead of management to arbitrate between the two groups. All that goes away if you put the different skills on the same team and provide well-defined business goals for the team as a whole.
I suggest watching this video from the CIO of Carmax where he explains how the teams are structured and the incredible time-to-market that they're able to achieve: http://forresterevents.net/video/2018/dt/9-0845-0920-mohammad.html
Overall, your concerns are valid, and you're a lot closer aligned to the thinking behind DevOps than you realize. I think you're simply getting hung up on the words and preconceptions about what it actually is.
Yet somehow everyone with pipelines eventually falls into that same trap. It's easy to ignore people that you don't have to interact with.
Take the dev and the ops and put the 2 guys on the same team and the delivery pipeline changes.
I suggest you go read The Phoenix Project by the guys that defined DevOps. You'd be surprised.
Did I say that they should be both developing the app and managing the infrastructure? You made that assumption. I intentionally kept both developers and ops engineers in my phrase.
Sit them together in a common team, and they will learn from each other and deliver a better product. The biggest killer of good ideas is the pipeline where you lob hand grenades over the wall to the next team in the queue.
You just explained the reasoning behind DevOps.
A big principle of DevOps is that you build end-to-end cross-functional teams, and that everyone is aligned to the business goal. That means incorporating other roles across the enterprise. Put designers, security, and product on the team. It can't be simply developers and ops. Build teams focused around specific deliverable initiatives rather than throwing things over the wall between departments. It cuts out huge swaths of hierarchy slowness.
If you're on 4 scrum teams, then that's entirely stupid and undermines scrum. The teams shouldn't organized to be project-based, the teams should be organized to form a tight well-functioning, and most importantly, PRODUCTIVE group.
One of the biggest values of scrum and sprints is to reduce the amount of work in-flight at once so that each thing can be completed in a shorter timeline. If everyone is on everything, then you're wasting everyone's time on context switching.
You shouldn't need more than 1 standup a day.
And if there's extremely high priority work that can't wait for the normal cadence, then it should be a simple matter of the Product Owner deciding an equivalent amount of unstarted work to push out of the sprint to replace it. The point is to make the person responsible for the decision holds the responsibility for that decision.
Otherwise you end up in the classic model of "we asked for a million things at once and it's the developers' fault for not delivering"
Would you agree that the Ops guys will do a better job if they better understood what Developers were delivering? Would you agree that the Developers would write better code if they had the input and advice from experienced Ops engineers?
President Moon rightly figured out the the easiest way to get Trump to go along with something is to simply give him the credit.
Always having to get the last word isn't a good approach to dealing with your users.
edit: "A brand is not simply an asset."
NO ONE else knows the "company". You're arguing semantics that YOUR CUSTOMERS don't see. A brand is not an asset. A brand is the company that your customer perceives. Your customers don't see your corporate structure (which is the entire reason for corporate structures).
Do some basic research on why brands exist. Here's a hint, you didn't buy SourceForge for the proprietary technology stack.
Take the valid criticism and act on it. Stop being a dismissive jackass to your users.
Good for you.
To your users, SourceForge is the company. You don't get to pretend history didn't happen because it's under new ownership.
Now stop claiming "my company didn't..." as it's patently false. Instead, go out there and build up positive mindshare to try to restore the brand that was so tarnished.
Wrong. Your company did. Just because you're part of the new ownership that eliminated the practice doesn't mean that it didn't happen. Earning back good reputation for a brand is a hell of a lot more difficult than earning slashdot karma.
You think this is bad, try a password keylogger implemented purely as CSS (no javascript):
https://css-tricks.com/css-key...
The real vulnerability in both this and the article example is allowing 3rd party code injection. If you can't trust the source of the code, the language being used doesn't really matter. There will be ways to abuse it.
Non-transferable means that Fox can't sell the rights to someone else. Whatever business unit owns the rights can be bought and sold wholesale however without negating the licensing rights. Fox can be sold with the rights can go with Fox in the sale. Rupert Murdoch isn't the license holder, some random business unit within 21st Century Fox is the license holder.
And there was much rejoicing.
Itâ(TM)s been illegal to install shake roofs in CA for over twenty years due to the fire hazard.
And what about Walmart? Oh right, Wally and his family donate to Republicans and Trump is doing everything he can to attack Bezos because of a personal vendetta.
Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.
A few conveniences like performance. I changed which build servers were running part of our monolithic process recently because it took 45m to run a step in JRuby that could be done with a native Ruby gem in about 10m.
Next up, replacing that Ruby gem with a NodeJS plugin that can do it in under 2 minutes... on the same hardware.
I came in to cleanup a project built by one of those guys. 2+ decades of experience and a Java architect. It was a PHP sure where he used factory factory factories to initialize the entire codebase.... completely ignoring that in PHP you get a new thread for every request. He left when he couldnâ(TM)t figure out why the web server had to be forcibly rebooted on a 45m cronjob.
The same site also used inline static JS to set the destination of top menu items:
Itâ(TM)s important to understand how a language behaves in context, not just be able to pick up languages fast.