Signs You're Doing Devops Wrong (infoworld.com)

snydeq writes: Misconceptions and flawed implementations may have many organizations missing the true upsides of devops, writes Adam Bertram in his article on devops practices gone wrong. "Saying that your company embraces devops and regularly practices devops techniques is popular nowadays, and it can serve as great PR for bringing in great talent to your team. But in truth, many companies — and technical recruiters — that are proclaiming their devotion to devops from the hilltops aren't really devops organizations."

Comments

Sign #8

[offa]

Expecting "Devops" to be a panacea and the answer to every issue you face.

Re:Sign #8

[Anonymous Coward]

s/devops/scrum/g

Re:Sign #8

[bickerdyke]

or Kanban

Re:Sign #8

[Spaham]

Sign you're doing it right : your site is offline 3 or 4 times a week.

Re:Sign #8

[Anonymous Coward]

> s/devops/scrum/g

Invalid sed expression. Two completely different things.

Re:Sign #8

[l3v1]

They are, still, it's a valid answer to "Expecting "Devops" to be a panacea and the answer to every issue you face."

Re:Sign #8

[Anonymous Coward]

sed expressions don't care if they are different things --- it's the beauty of unix.
the machines that came before *did* care.

Re:Sign #8

[luis_a_espinal]

> s/devops/scrum/g

Invalid sed expression. Two completely different things.

cat /lost+found/*sarcasm* | sed 's/you/whoosh/g'

Sign #1

[Anonymous Coward]

You're calling it "DevOps"

Re:Sign #1

[Anonymous Coward]

ZING!

s/devops/agile/

[Anonymous Coward]

Misconceptions and flawed implementations may have many organizations missing the true upsides of agile, writes some guy in his article on agile practices gone wrong. "Saying that your company embraces agile and regularly practices agile techniques is popular nowadays, and it can serve as great PR for bringing in great talent to your team. But in truth, many companies — and technical recruiters — that are proclaiming their devotion to agile from the hilltops aren't really agile organizations."

Sign #9

[offa]

You treat "Devops"/Agile philosophy like a buffet and choose those elements that you like and disregard anything you don't as potentially slowing you down. getting in the way, or thinking that you are "smarter" somehow and then wonder why you don't get the desired results.

Re:Sign #9

[Anonymous Coward]

OK, why don't you tell which version is the one that works?

I suspect that you prefer to wait until someone have used one of the versions until you say that they were using the wrong one.

True Scotsman of our time.

Re:Sign #9

[Anonymous Coward]

I totally disagree.

The key to successful agile / anything implementation is adopting it to your specific circumstances. Doing something that doesn't make sense or works against you because "that's what the book says" is imo the definition of agile done poorly.

Take the things that work, tweak or substitute the things that don't. As long as you understand the intention of the thing you arn't doing/are doing differently and how it factors in to the big picture, you should be fine.

Re:Sign #9

[KGIII]

I'm glad you asked... I could preface this with a long-winded history but I'm going to skip that (this time) for the sake of brevity (really). Well, I'm going to *try* to be articulate.

I started programming because I had a need to. I did this for quite some time along with a Comp Sci grad who was my first employee but he didn't do as much of the programming as one might think -- he had other things to do as we were really pushing the hardware further than it was meant to go. Imagine, if you will, the 1990s and, by the end of the 1990s, we were working with data sets that were nearly a TB in size and spread out over giant disk arrays.

Anyhow, the business grew. This meant that my time was severely constrained. I was putting in 20 hour days, often for weeks at a time, and sleeping in the office. This could not last and eventually I hired competent people who were skilled in the mystical art of programming. They were far more adept than myself and much quicker. They were expensive but worth it. They even went so far as to re-write the entire code base because, "Code comments go in the code, not on a coffee stained index card on your desk, asshole!" (That's pretty close to verbatim.)

Now, we didn't have a name for it and I don't know if there is a name for it. But, I tried micromanaging and I tried to keep up and to keep things directed, I really did. I tried to be involved in every commit and every push to production. I tried to understand the new complexity and the new functions when, really, all I needed to do was help them tweak algorithms and help them learn to automate data manipulation tasks. I was still putting in 20 hour days.

Then, I realized I'd hired them for a reason. I'd hired them because they were the best in their field. I hired them because they knew what they were doing and were better at it than I was (which is not a hard task, let me assure you). I paid them very good salaries and gave them great benefits because they were keeping my company afloat and enabling us to expand exponentially. Yet, I wasn't really letting them do their job to the best of their ability.

See, I learned to shut the hell up and get out of the way. Now, I suspect there's no "Shut the fuck up and listen to smart people" mode of development but I can tell you that it is quite successful. I gave them clear directions. They told me what they needed. They told me when it would be done. I gave them the tools they asked for, not the ones a vendor suggested, and shut the hell up and got out of the damned way.

In the interests of brevity, it worked. I am where I am today because of them and because of my being willing to set my ego aside and accept that I'd hired people for a reason. It was hard, this was my baby. No, seriously, it was damned hard to let go. Now, I don't know what they did internally but it looked like they took directions, planned, and then executed. The difference is, they were given what they said they needed, rewarded for their effort, and had a vested interest in success. They didn't have a leader, a supervisor, or anything like that. They had a goal, picked what they did best, and worked on it until it was done.

I don't know what you call it but, well, hire smart people and pay them well. Let them do what you hired them to do. Give them help when they need it. Give them the tools they ask for. Give them a reason to KNOW that they can screw up. Be willing to screw up and admit your errors and learn from them yourself. Treat them like adults and they'll sort out who does what and when - all on their own and without any input from you beyond giving them direction. If they can't then you hired the wrong people.

So, yeah, thanks for asking. That's what worked best for me. Try it sometime. It means letting go of your ego, it means being willing to admit you're wrong, and it means treating people like adults who deserve to be rewarded for hard effort and earn a decent living. It means being smart enough to know what you don't know and being willing to ask someone who does

Re:Sign #9

[dotancohen]

See, I learned to shut the hell up and get out of the way. Now, I suspect there's no "Shut the fuck up and listen to smart people" mode of development but I can tell you that it is quite successful.

In my entire professional life, I've only worked with one boss like that, actually recently. He got a great product, myself and the other devs had a blast and learned a lot, and the code is some of the most maintainable, feature-complete and bug-free code that I've seen outside of popular open-source projects (where code quality matters).

I'd love to work for you.

Re:Sign #9

[KGIII]

I am, quite happily, retired. I sold out about eight years ago and I sometimes miss it but I'm never really unhappy with my choice. The thing is, it doesn't seem like this is a difficult thing to figure out. I mean, hell, I managed it. I'd never taken a single business course in my life. I'm a mathematician, not a manager or a business graduate. The hardest thing was letting go, emotionally, and learning to listen to smart people. I don't know everything. I can't. If I need those skills then I should get the best person I can to provide them and then listen to them when they tell me what needs to be done. Otherwise, why hire them?

It was definitely a life-changing event. Or, more accurately, a series of events. I certainly did not expect to be where I am today. I expected to be in academia somewhere, maybe at an old rustic New England university, and driving an antique Saab to work while I lived in a fixer-upper house from the turn of the 19th century. But, life throws you strange chances and, if you dare, you can try to take advantage of those things and do something different. I was lucky and happened to be in a position where I was able to take risks and then capitalize on it.

I think that, in particular, was probably what led to the above mentioned management style. "Buggered if I know? That's why I hired you. Tell me what you need and I'll get it for you." Also, I've no moral qualms about poaching good employees, training them, or even sending them to school if they show talent. There weren't a whole lot of traffic engineers at the time and most of them were in fleet management, things like mine vehicular flow management, or dealing with choo-choo trains. Damned right I'll pay for good talent and pay to train someone or cross-train someone who has an aptitude.

Then again, I sometimes wonder if it was that I didn't have the preconceived notions and I had no idea how to manage people "by the book" that made it work? They weren't employees. They are people without whom the business would have been impossible. Sure, we sometimes made errors and had to crunch to meet deadlines but, yeah? We buckled down and did it. Maybe management school would have killed that. I don't really know.

I'd probably write a book detailing my experiences and lessons learned but I doubt anyone would read it and actually listen to it. I do, sometimes, hope there's a manager or two on Slashdot that reads these responses from people like you. They won't listen to me but they might listen to you and understand that it impacts you in a meaningful fashion and that also impacts the bottom line. Not to mention, from the way some of you folks describe it, it must suck to be a "human resource." Even when we finally had over 200 employees, we didn't have an HR department. I kind of find the idea appalling.

Re:Sign #9

[dbc]

The best boss I ever worked for was an ex Israeli commando officer. When I say that to most people, they are often a little frightened. But think about it: 1) A commando officer never sends his people in without making sure everyone has a very, very clear understanding of the objective. 2) A commando officer asks what they need and gets it for them or adjusts the plan. 3) A commando officer asks if they can meet the time frame or adjusts the plan. 4) A commando officer truly cares that all his people are as healthy at the end of the operation as at the start.

Anything less results in having to write very unpleasant letters to parents. The same simple steps, especially #1, will go a long way in a software organization, too.

Re:Sign #9

[Anonymous Coward]

You keep doing agile and I'll keep delivering clean, reliable and easy to maintain software and keep doing it quickly.

I've spent years doing Scrum and it's a fucking awful process when you do is right.

I've seen the bullshit way assholes put together their stories in order to get them to fit into a sprint; then fess up that's it's not really production ready and not going to be, that's a few stories away.

Fuckers.

Re:Sign #9

[krisbrowne42]

Alas, on a day I don't have mod points and actually want them... This needs to be a book, so I can leave it anonymously on the desks of a number of managers.

Re:Sign #9

[KGIII]

That makes perfect sense to me. I paid for my education by way of the Marines and the GI Bill and, then, scholarships and working as much as I could. Life has been much different than what I expected when I was a child. I don't think a day passes where I don't think back and ponder the circumstances that got me here. It's easy to say that there was hard work and intelligence involved but, really, much of it just comes down to dumb luck.

Mostly, I was in the right place, at the right time, and able to take risks. It's because of that that I don't look at other people and assume that they should have become something other than what they have. They had different circumstances, choices, and risks to weigh. Life isn't like a Choose Your Own Adventure book where you can flip ahead and then go back and decide which path to take.

We tried this but accounting killed it because..

[fred911]

Janice in accounting don't give a fuck!

What's DevOps?

[Art3x]

No, I haven't read the latest InfoWorld article submitted by snydeq. But I'm pretty sure that it fails to answer the question, what exactly is DevOps?

buzzword-laden definition: just google devops and you'll find enough
best-guess definition: Development and Operations working together
low-budget definition: Development and Operations being the same person

By picking the right companies (that is to say, low-budget ones) I'm happy to say I've been doing DevOps for over a decade!

Re:What's DevOps?

[Greyfox]

Developers having to do operations and getting paid operators salaries. Kind of like how all the companies currently looking for "test automation engineers" require Python and C++ and really want a developer who will take a tester's salary.

Re:What's DevOps?

[Anonymous Coward]

We are the FLOSS mafia. Open your source and prepare to be downloaded. Your code and algorithms will be adapted to run on cross platform.

Re:What's DevOps?

[sithlord2]

Actually, it's quite simple: DevOps is an ATTITUDE. Nothing more, nothing less.

For Developers: No more: "It works on my machine, It's Operations' problem now".
For SysOps: No more: "I won't automate it because then everyone can do it and I like job protection."

That DevOps-attitude has a goal: Continuous Delivery. Automate your deployments, so you can deploy at any moment. Involve your developers in the monitoring proces, so they can get involved when things go wrong in production.

Re:What's DevOps?

[pci]

We have a few "test automation" people floating around, their managers want QA people embedded on their development teams and they only want to do it was to have programming skills as a job requirement. As a bonus it is a developer position/salary.

Re:What's DevOps?

[Anonymous Coward]

No... it is Microsoft junior admins finally scripting their shit like the Unix folks have been doing for years. Now that they have a decent scripting language in PowerShell, they can finally play with the big boys. I tell you, with Dave Cutler out of the picture, the Microsoft OS folks have actually been doing a decent job lately. That man's destructive legacy will be felt for years to come, but it is finally beginning to fade.

Re:What's DevOps?

[whitelabrat]

This is the correct definition of a DevOp. Developers who have to do Ops, because there are none. Therefore a developer you try to code your way out of the manual slogging that is Operations.

It seems to have evolved to mean operations automation, but generally due to a lack of operations staff.

So tools like Chef, virtualization on an outsourced infrastructure, and heavy API use are not uncommon. Success usually requires folks who have operations experience and code skills. If you do it right, you get to sleep at night. If you do it wrong all the old graybeards laugh at you.

Re:What's DevOps?

[art123]

PowerShell has been available for 9+ years.

Re:What's DevOps?

[barbariccow]

Powershell is not a decent scripting language. But you have cygwin which supports bash on windows. That's a nice batch language. Or you can run python on windows, that's a nice scripting language.

Re:What's DevOps?

[ardave8952]

I've also seen DevOps manifested as developers doing Operations and getting paid developer salaries. It's little solace that the dumbass organization has chosen a bad economy, that is thinking that they can pare down their Operations team but not realizing their developers are losing weeks to learning the intricacies of creating cloud configuration scripts, when that's not the work you want to be doing as a developer.

Devoops

[sonamchauhan]

1. You fired all your operations people and gave developers pagers.
  --OR--
1. You fired all your developers and gave your operations people compilers.

Re:Devoops

[Anonymous Coward]

It's amazing how much clarity this brings to a concept that is otherwise a game of bullshit bingo.

Re:Devoops

[Etcetera]

1. You fired all your operations people and gave developers pagers.

  --OR--
1. You fired all your developers and gave your operations people compilers.

Bingo. Devops means talking to each other and walking in each others shoes a little. It does NOT mean that either side is dispensable, and it's certainly not a replacement for advanced skill-sets and knowledge in either domain.

It's also not an excuse for not dealing with best practices on both sides. The fact that it compiles and you've successfully shipped a black box Docker that seems to pass the tests doesn't mean the internals have been properly designed and engineered, which means you've made fixing problems and dealing with fires (traditionally the domain of the SysAdmin/SysEng, but they'll wake up a Dev if they have to) much more difficult. Frontloading complexity into your automation framework doesn't make anyone's life easier except the person doing the most rote of tasks. The equivalent is making a nice, shiny, impossible-to-repair car that's nothing but code spaghetti and mush underneath the hood because you didn't have a human sanity-checking what you put out.

Re:Devoops

[dargaud]

As someone who has gone to Antarctica to install and run the software I write, I can proudly say I've been doing Devops for decades ! And I just learned the term a minnute ago...

Re:Devoops

[KGIII]

I've been to your site before! I recognize it from mousing over the penguin images and they yelled at me. It took me a minute to figure out how the squawking was being initiated the first time I visited. Now I think I know how I got there. I assume that I followed your signature or a link you posted. I might have just been looking for penguins, I guess, but that's unlikely.

No, I have no real point but I do encourage folks to click your link and check out the penguins. I got distracted so I have no idea what actually did there but, damn it, penguins!

Re:Devoops

[dargaud]

I got distracted so I have no idea what actually did there but, damn it, penguins!

Penguins will do that to you...

Re:Devoops

[gweihir]

Hehehehe, nice!

And, after a bit of time you are wondering why both your infrastructure and your new software is getting worse and worse.

Re:Devoops

[wasteoid]

3. You hire a college grad to do both the developer and the operations jobs, with the operations salary.

Re:Devoops

[Anonymous Coward]

In the meantime, you've also fired all your network engineers and security engineers ... because infrastructures are a service ... or some bullshit like that.

TIL I've been practicing DevOps

[Anonymous Coward]

Huh, apparently I'm buzzword compliant, even with the new and improved buzzwords

Devops sounds like Special Ops

[Anonymous Coward]

Elite coders doing tactical shit no one else can.

The name lends itself to good marketing and make belief.

Re:Devops sounds like Special Ops

[Anonymous Coward]

Unless You've grown to give the word "special" exactly the same connotations that people used to give to the word "retarded".

Can anyone keep up all these bullshits?

[Taco Cowboy]

I am a developer, I have been a developer for a number of decades, and I run businesses which deal in the tech scene in many location worldwide

I can tell you one thing about these 'devop', 'scrum', 'agile' or whatever the new fuck-of-the-day trend they manage to come up ... PROGRAMMING IS PROGRAMMING and everything else is just addons

I have let some of my branches experiments with some of these bullshit schemes, just for experiment sake - and the result, at least to me, have yet to be impressive

Back when I started we have none of these, and yet we managed to squeeze in almost unimaginable functional stuffs within really ridiculous tiny confines (4K of RAM, 2K or ROM, for example) and today when we have almost unlimited memory space, all these bullshits that have been advertised as 'cure all' has yet to deliver

Perhaps I'm an old timer, perhaps the new hipster culture demand to have all these bullshits before they could even start doing anything, I dunno, but my feeling is, with or without these bullshit the most important factor is the PEOPLE

If you have the right folks with the right mindset, you will get great result

If what you ahve are lousy people with 'duh!' mindeset, no matter which of the new-fangled bullshit you adopt it ain't gonna give you any miracle

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

I love you mate... i love you...

Re:Can anyone keep up all these bullshits?

[mfearby]

I agree. There are so many methodologies out there. I discovered a new one the other day: "kanban". If I were to sum it up myself it would amount to not throwing the baby out with the bathwater and keeping what's good when you go to redevelop a system (at least, that's the impression I got; I'm not wasting valuable hours really delving into yet another methodology).

I had a boss once whom a former colleague told me once had instructed him to "stop planning and start doing". This was because he had put in a week or two writing a Word document explaining the system and not actually writing it. We're not talking about a massive system either, just an in-house web page in ASP to handle something simple. At the time, we laughed and thought the boss was a loon, but almost 20 years later I've come to agree with him. You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.

I guess the methodology fanbois would say "agile" is the way to go, and something like it would probably be right. I'm guess I'm an agile developer these days but I don't know a thing about what the methodology actually says. I just get stuck in and "do", and occasionally, if a system is big enough and I'm wary of the users changing their minds all the time, I'll commit the important bits to paper and get them to sign off. Other times, when I know exactly what's needed and we're all on the same page, and the clients don't have that look in their eyes that says they'll be changing their minds a lot, I'll just get stuck in and write the thing without a full-on design beforehand. I find that most designs/plans/whatever are useless by the time the project's over anyway.

The best methodology is a good separation of concerns with plenty of comments. The rest is just all flash and no meaning.

Re:Can anyone keep up all these bullshits?

[arkhan_jg]

It depends what is meant by devops.

If it means the sysadmins and developers talk to each other and work together in a healthy relationship to deliver stable, scalable apps with heavy use of automation to cut down scut work and human error from both sides - that meet the goals of the organisation - then you're doing it right.

If it's just a synonym for badly run agile, with devs slapping together whatever to meet arbitrary goals rushed into production with insufficient testing, while sysadmins end up firefighting all the time because devs just frack it up even worse now they push direct to production; then it's just another bullshit buzzword.

Sysadmins need to be part coder these days to do their job properly with automation and flexibility; devs need to be part sysadmin so they can factor performance and stability within sane budgets into their designs.

I'm a traditional sysadmin, but I've brushed up on my coding from my undergrad days the last couple of years, and have a couple of my own projects deployed now. I work pretty closely with our 3rd party developers, so can understand and support their requirements better, and they work with me rather than round me. Is that devops? I dunno, but it beats the hell out of the usual silo'd suspicion and blame game.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Amen that. I quite enjoy programming and like to imagine that I'm moderately good at it, but the management shit that goes along with it makes me yearn for retirement.

Out of curiosity: are workers in more traditional engineering fields (say civil or mechanical engineering) forced to endure this "management by half-arise, ill-considered fashion/fad" in between getting their work done too?

Re:Can anyone keep up all these bullshits?

[jandersen]

I am a developer, I have been a developer for a number of decades, ...

Me too - and I agree. Well, mostly. I think these fads are really just about management trying (and failing) to catch up with what developers are. Agile is really just about trying to formalise what a sensible development team already does: talk to each other, make changes to designs when needed etc. The reason it fails is probably that in formalising the process, they try to introduce yet another one-size-fits-all concept, and developers are just not like that. A sales team perhaps, would like it - sales people often seem to enjoy the superficial ceremonial rah-rah, but engineers tend to think much deeper than that and reject it. Perhaps we shouldn't always, but there you are ...

'Devops' is something different, I think. Ideally - or naively, perhaps - you would expect it to be something like sysadmins who know how to develop code (and do this as a large part of their jobs). In reality it seems that management thinks of this role as something like an automation process where you can let unskilled labourers push the buttons on machines that do what used to be done by highly skilled craftsmen. Whether it can really work in the long run remains to be seen; automation is certainly helpful in a cloud environment, where you may be handling 1000s of nearly identical systems, but somewhere in the process you really, really need to have people that are very insightful into the whole setup, and that is quite often missing.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Which of course makes me think of that wonderful question:

PROGRAMMING MOTHERFUCKER: DO YOU SPEAK IT!!??

http://programming-motherfucker.com/

Re:Can anyone keep up all these bullshits?

[Anrego]

Agree it's about people and shitty programmers are gonna be shitty regardless of process.

That said, as someone who's seen adoption of agile make a huge (mostly positive) difference, I do think changing methodologies can sometimes be a good idea... if for no other reason than it gets people into a "doing something different" mindset rather than a "business as usual" mindset.

I'll also say that software as a business has changed dramatically. It was never just about programming, but I certainly feel that the code itself was a far bigger factor in the overall success of a project than it is now. These days the actual code seems to just be a minor detail amongst contracts, requirements, licensing, and layers of internal and external bureaucracy. A lot of newer methodologies and tools seem discretely aimed at getting middle and upper management out of the developers way and letting programmers sit down and work on the same thing for a few weeks without some higher-up making them switch to whatever their biggest fire is at the moment.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

You can go too far in the other direction. Amount of design and planning has to be proportional to the size of the project. Sometimes, yeah, you can just jump in and write the damn thing, but other times you really do need to sit down and think things out at a certain level or you'll get half way though and realize your foundation won't support some major piece of the project.. and then the hacks start.

Also I'm a huge fan of prototypes as part of the design phase. Easiest way to identify design hickups in tricky bits of a project is to hack out a quick prototype to see if what you've got on paper is gonna make sense in code or pick up on realities you might not have accounted for. Especially true when interfacing with other hardware/software/services, because what the spec says and what the thing does often don't line up perfectly, and fixing the "thing" isn't always an option.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

I think the huge difference between software and traditional engineering fields is a set of accepted standards and well understood principles.

We know how to build bridges. Sure we occasionally push the envelope and do something crazy, but that craziness is based on accepted principle.

With software, we still really don't know what the hell we're doing. Everyone's got a different idea of how everything should be done, and there is a whole smattering of success and failure cases for just about every approach. We're still trying to figure out "the one true way".

Re:Can anyone keep up all these bullshits?

[goose-incarnated]

badly run agile,

You repeat yourself ;-)

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

You got stuff done in them thar olden days BECAUSE you only had 4k of RAM.
You want to add a spell checker? No can do - 4k RAM.
You want a team of brilliant scientists to add in a learning AI? No can do - 4k RAM.
Want a team big enough to develop everything in time? We've only got 4k RAM, the team is me!

Scrum and Agile are about getting a team to work effectively.
Devops is a role where you bridge the gap between developers and operations (all those bitty scripts that make operations faster and more effective - doing that properly).

You're right, if you have the right folks with the right mindset it'll get done. But you're going to be very lucky to find them, and keep them.
A good business will take the pragmatics approach and hire one good person and 9 average people and organise them properly.

Re:Can anyone keep up all these bullshits?

[Z00L00K]

It doesn't really matter what you call an agile development style or if it's even documented or not (OK, it's good if there's a trail in some way so you can see what has been done or not).

What is really scary is those that tries to impose the waterfall style of development - it's something that only works if you design simple hardware items with few ways it can go wrong. On software it can cause a project to go on for years (Half-Life 3 anyone).

Re:Can anyone keep up all these bullshits?

[Big Hairy Ian]

Yep programming is programming. Agile and Scrum are about project management, DevOps is simply applying similar techniques to the maintenance and infrastructure management phases of ALM. Yes Taco like you I started out with the system specification written on the back of a packet of cigaretts. Just imagine a bunch of management consultants have taken the whole "Writing the spec on the back of a packet of cigs" and wrapped it up in a load of techno bable so that now instead of a packet of cigs you are presented with the spec written on a rubics cube which has been scrambled. Devops is simply extending this to the plug it in and see if it works approach to application maintenance :D

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

I know of a person who leads a "devops" at a large company who is a complete idiot. The sight of him maketh me sick . The fella couldnt write a Fibonacci sequence generator even if you put a gun to his head. Oh wate he dosent know what Fibonacci is .. he can barely add 2 integers in turbo pascal . YUCK

Re:Can anyone keep up all these bullshits?

[eulernet]

What is the correct balance between "planning" and "doing" ?

"Doing" works for people with plenty of experience, but they are rare.
"Planning" works when the project is very complex, but it is rare
The correct cursor is something between "a little planning, a little doing, and we see what we reached", which is basically agile's definition.

I'd like to share my experience: I wanted to become an agile coach (yes, shame on me !).
This was because I saw the opportunity to help people become better, but that's not really what agile became nowadays.

And I realized that Agile is not for developers, but for managers.
In other words, it's not designed to help developers, but to make money out of managers.
You have to agree that the vast majority of managers are completely clueless, so they doubt about their own skills.
Agile, or most exactly Scrum and Devops, are designed to tell them: you don't understand software development ? No problem, you'll only have to follow a basic algorithm and we promise you that all your problems will disappear.
I agree that this is quite dishonest, but hey, the goal is to squeeze money out of companies, and managers can use their budget for this !

What is funny is that most agile gurus are not decent developers.
They'll explain that such agile game will help people realize something, but they are quite clueless regarding programming.

Re:Can anyone keep up all these bullshits?

[Anrego]

I think it's a little less "wool over their eyes"-y and more about creating a process where the high level stuff managers care about is easier to track and control and giving developers space to do their thing without managers meddling too much. It creates a clear(ish) demarcation point. Managers worry about things at the sprint and maybe story level, developers make it actually happen. Once it's decided that it's happening, developers (in theory) are left alone to actually do it.

Contrast that to "pre-agile" style where managers would just poke in and out and ask about whatever random bit of functionality they happened to care about at the moment or re-prioritize stuff because someone send them an email. What agile does for the developer is codifies "I have 2 weeks to code this specific thing, go away and let me do it".

Re:Can anyone keep up all these bullshits?

[JustAnotherOldGuy]

Bingo, and very well said.

Add to everything you just said that programming, by and large, is a solitary sport, and a lot of this "management fad of the week" shit comes into sharp focus as nothing more than new and innovative ways to waste everyone's time by talking about what they're doing rather than actually doing it.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

You can find the rest of us HERE mate.

Re:Can anyone keep up all these bullshits?

[JustAnotherOldGuy]

You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.

Absolutely.

And quite a few companies these days make people spend a boatload of time reporting on what they're doing rather than actually doing it.

It seems the big thing for the last ten years or so is have everyone do spend work hours doing Weekly Update Reports, Daily Metrics Summaries, Monthly Milestone Wrap Ups, etc etc etc.

And then they wonder "where did the time go" and "why stuff isn't getting done".

Re:Can anyone keep up all these bullshits?

[utahjazz]

You subscribe to this methodology: http://programming-motherfucke...

Re:Can anyone keep up all these bullshits?

[lorinc]

You're old. Back then only few people did programming, and those where excellent at their work because it was highly selective and you needed to be passionate. Now, programming is a mainstream job, which means that millions of people will do that as a day job without the ability nor the motivation.

It's one of the side effect of massive growth. The few interesting guys of a specific domain get surrounded by many mediocre guys that just don't give a shit. You can see that pattern in every single domain.

Putting a huge amount of functionalities in 4K takes a lot of talent and dedication, for sure (never did that myself). I'm pretty sure you would find more people today capable of doing it that 30 years ago. However, it's not what you see. What you see is the massive army of average Joe who don't give a fuck about the field or doing their job the best they can, and as such are completely uneducated. So yeah, basically all these new methods are there to mask the mediocrity and the lack of motivation of the majority of people working in the field.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Netflix describes devops as "programmers who architect, design, develop, deploy, and support their own creations. They get called in the middle of the night when their program breaks in prod, not the sysadmins". Or something along those lines. The best explanation of devops I've heard is "devops is a mindset, like agile or lean".

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

devops is a buzzword for firing most\all your sysadmins (or not hiring them in the first place) and making your developers pick up the slack. It provides worse outcomes and wastes the developers' time, but it looks great in CIO-focused magazines.

Re:Can anyone keep up all these bullshits?

[Gazzonyx]

I over plan because every time I've had someone not writing code tell me the scope of the thing I'm writing and I ask "will it have to do xyz?" it will eventually end up having to do xyz no matter how flatly it is denied. Last week the turnaround on one of my silly questions ("is the service always run under that exact user?") was less than a day.

I had already implemented and documented the new variable and which properties file it went in by the time I was told I'd need it. Ditto for things that will only ever connect to a service on the local server - use a socket and protocol to connect to the localhost, because it will be connecting from somewhere else and you can't redesign it at that point.

That being said, I agree with your point in principle, but with the huge caveat about scope creep and accurate project requirements.

Re:Can anyone keep up all these bullshits?

[eulernet]

What agile does for the developer is codifies "I have 2 weeks to code this specific thing, go away and let me do it".

I wanted to agree with you, but you are clearly too much obsessed by Scrum !
Frankly, this "2 weeks-sprint" is probably one of the least agile techniques.

It's like saying: we are in the Titanic, we need 10 miles to turn right. Hey, there is an iceberg in front. No, we need 10 miles, so we'll take 10 miles !

Agile is here to force managers focus on their work, and let the developers focus on their work.
Forget daily scrums, forget sprints, just do it in the agile way: as it comes.
How can I balance between planning/cutting tasks and coding/testing, when software changes during its development ?
I can assure you that 2 weeks sessions will not solve your problem !

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.

Absolutely.

And quite a few companies these days make people spend a boatload of time reporting on what they're doing rather than actually doing it.

It seems the big thing for the last ten years or so is have everyone do spend work hours doing Weekly Update Reports, Daily Metrics Summaries, Monthly Milestone Wrap Ups, etc etc etc.

And then they wonder "where did the time go" and "why stuff isn't getting done".

Ummm, but I need the TPS reports to have the proper cover page, mmmmk. Also, I'm gonna need you to go ahead come in tomorrow. So if you could be here around 9 that would be great, mmmk...

Re:Can anyone keep up all these bullshits?

[Anrego]

Well, in scrum specifically that's what all the rebalancing is about. You ask "does this amount of work make sense for the window we've got (2 weeks)" and if the answer is no, you add/subtract stuff as required.

I'm not saying it solves all the problems or has to be rigidly adopted to see any benefit, but I feel like it legitimately does address a lot of very common problems in software dev teams in a reasonably effective way.

Chunking stuff up into managable pieces has always been good practice for schedule management, all scrum does it provide a well thought out and consistent way of doing it. The caveat is you have to accept that not every task is going to fit into this model. Sometimes you need to just have a dev pound on something for a month until he figures it out, and breaking it up into "deliverables" just adds overhead, but I feel like if you can get _most_ of your stuff into a "small deliverable/demonstratable pieces" mindset, it's a good thing.

Re: Can anyone keep up all these bullshits?

[Lije Baley]

And don't forget that computer folk have specific FLSA exemptions which let management disregard the kind of professional behavior that those in the other disciplines have.

Re:Can anyone keep up all these bullshits?

[eulernet]

I maintain that this 2 weeks is completely arbitrary, and leads to unregular velocity during the session.
You'll get most work at the beginning, and the effort disappears at the end of the session.

The worst thing is that some of the nice features get cut in so many parts that we can only implement the least costly ones.
This leaves the whole features unfinished and creates a lack of satisfaction.
Perhaps it works well for new teams, but for experienced teams, this is a serious problem.

Also, an experienced manager will know when to negotiate (which is what agile encourages) and when to stop negotiating (which is what agile discourages).

Re:Can anyone keep up all these bullshits?

[BVis]

This, so much this. "Devops" (which should be "developers who know some sysadmin skills" and "sysadmins with some programming skills", but is usually "developer and sysadmin are the same person") and "Full-Stack Developer" (instead of "developer", you have "developer-DBA-QA-XYZanything else we can make them do") are code for "Let's hire one guy to do 2 or 5 jobs instead of hiring 2 or 5 people like we would do if we were less insane and less cheap." With devops, you get pressure from your lead dev or architect about why you're not closing more tickets or writing more code, and you get pressure from the idiot walking-haircut MBA running the show for not releasing each week with the features that are the exact opposite of what they asked for the week before. You can't code if you're doing sysadmin work, and you can't do sysadmin work if you're coding. But they try to make you do it anyway, because they can't "increase headcount".

Re:Can anyone keep up all these bullshits?

[lgw]

As far as I can tell, "devops" means "fire all that sysadmin baggage, and just pile that work on developers with no ops experience - it will be fine".

Re:Can anyone keep up all these bullshits?

[jbengt]

Out of curiosity: are workers in more traditional engineering fields (say civil or mechanical engineering) forced to endure this "management by half-arise, ill-considered fashion/fad" in between getting their work done too?

Not so much fashion/fad in management techniques, but you still get plenty of relatively clueless managers, changing scope in the middle of the project, and the occasional fashion/fad in engineering solutions.

Re:Can anyone keep up all these bullshits?

[BVis]

I agree that shit programmers are going to be shit programmers no matter what, but another problem is shit managers that use the methodologies of agile/scrum/kanban/whatever to further isolate themselves from accountability by blaming everything on the developers. If you're an MBA who can barely run a toaster, yet you're in charge of directing a software project of significant complexity, the shit rolls downhill until your once-good developers are now burned out husks who are indistinguishable from shit programmers.

I actually like Agile, we implemented it fairly well at my previous job. The thing I like about Agile is that it defines everyone's role and discourages people from going outside them. We had an MBA who thought he could make every decision related to a project whether he was qualified to make it or not (and for most of them, he wasn't.) Labeling him as the "product owner" and defining his role to be limited to adding tickets to the backlog was better than him just trapping all the devs in their cubicles and talking their ears off about how they had to implement his stupid-ass decisions, with no accountability or documentation.

Plus, there was one moment of pure smackdown that was quite possibly the best moment at that job that I ever had. We were in a retrospective meeting, looking at a particular ticket. While the page in question was being opened up, he pointed at a misalignment on the home page and said "When are we going to fix that?" A few of us said, nearly in unison, "Did you add that to the backlog?" He gave us all a sour look because he knew he'd been caught not doing his job, when his core competency was not being held accountable for anything.

Re:Can anyone keep up all these bullshits?

[johnnyb]

Or it means "my sysadmins got bored and learned Python" or "sysadmins doesn't sound as cool as devops".

Re:Can anyone keep up all these bullshits?

[THE_WELL_HUNG_OYSTER]

Contrast that to "pre-agile" style where managers would just poke in and out and ask about whatever random bit of functionality they happened to care about at the moment or re-prioritize stuff because someone send them an email

Um, no. pre-agile we had the Capability Maturity Model, Rational Unified Process (RUP), Adaptive Software Development (ASD), Extreme Programming (XP), and many others. And to do any of these "properly" required spending serious amounts of money on training, consulting, auditing, and oooo... don't forget "certification". Entire mini-industries are spawned to handle each of these, for each new "process". Each of them spawn "experts" or "gurus". Some are even able to make doctoral theses out of it.

Sound familiar? Agile is just another one of them. It is not a paradigm shift.

Whoever said in an earlier comment that this is about money is right: all of these software engineering paradigms are money grabs. Doesn't mean they don't work for very specific projects in specific circumstances, but the primary goal is for the Tailors to sell the Emperor some New Clothes.

The bottom line is that there isn't any single software engineering/development process that works well for all organizations, for all projects, just like isn't a Unified Field Theory.

Re:Can anyone keep up all these bullshits?

[rwa2]

And I realized that Agile is not for developers, but for managers.
In other words, it's not designed to help developers, but to make money out of managers.

Oh, perhaps that's the version of "agile" that your managers pushed on you. Agile as specified by the original gang of four had lots of protections for developers. I can understand why most managers end up throwing all that stuff out.

* Developers are the only ones allowed to estimate the size and dependencies for each task.
* The business side is only represented by the Product Owner, and they're really only allowed to interact with developers during sprint planning and a bit during sprint retrospective. They can insert and prioritize tasks in the backlog, but they are not allowed to put in more work than the developers have estimated that they can finish during the sprint cycle.
* The Scrum Master is more of a mother to the team, keeping time, keeping score, and making sure all of their needs are met so they can be productive. This means breaking down blockers, shielding them from external stakeholders, the Product Owner, management, useless meetings, angry spouses, requirements and schedule changes (the sprint backlog CANNOT be changed once set in motion, the only proper abort sequence is to just cancel everything and give everyone the rest of the spint off), hunger, personal demons, indecisiveness, sexual urges, dirty laundry, etc. so developers can fully focus on their task in progress and keep their velocity up.
* Developers are really left with only two responsibilities, which are admittedly extremely difficult for most nerds:
    1) accurately estimate the size of each task (experience and collaboration are key)
    2) get the tasks they've committed to completed during the sprint without getting distracted by OOOH SHINY!
And of course there's reporting on blockers during standup, but that's, like, the least important part of agile that everyone seems to fixate on.

-- someone who had some CSM training way back when
And yes, Ops and therefore DevOps is way different, much more schedule and exploration and interrupt-driven. That's why they tend to use the simpler planning-less Kanban-style stuff.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

You're the kind of person I want to work for. I'm so sick of this hipster bullshit getting in the way of actually getting the job done. Unfortunately the workplace has been overrun by these new-age "thinkers", which is probably why I'm having such a shit time finding a job right now.

Re:Can anyone keep up all these bullshits?

[kanwisch]

I guess I'll say DevOps is hard when done right. I live in a space which has app devs, dev ops, and ops. Since none of that OP's Signs apply maybe we're doing it right. But I would argue it does work well. In reality, Ops is a shared service. Dev isn't. DevOps is a hybrid model and facilitates the challenges of the other two disparities.

As for this off-topic bent on Agile or whatever, be cautious about its evaluation. "Agile" is often just cowboy programmers using that as an excuse for no planning or design at all. And no commitment that has the needed parties in agreement. This is especially painful for shared groups like security and infrastructure.

Agile, waterfall, critical chain, side-by-side, blah, blah are all tools. The best places use those for specific reasons to improve likelihood of successful results. But some kind of planning is required if a business wants to actually create an annual budget and develop projections. Marketing actually needs to know when new products and services will be available MONTHS in advance in order to properly prepare the marketplace. These are facts, not PHB silliness. I suppose if you're a small consulting software shop some of that might not matter, but I suspect most here don't sit in those seats.

Re:Can anyone keep up all these bullshits?

[tnk1]

It's a sysadmin who can code to a certain extent. Most of the sysadmins that I know are now DevOps Engineers.

DevOps is not supposed to be a job title, it was supposed to be a philosophy for Development and Operations interacting. Which meant that you'd still have Developers and still have System Administrators, they'd just integrate more closely.

Needless to say, it now functionally means a sysadmin who can do light coding (useful for software defined cloud stuff like AWS) and understands certain tools like chef, puppet or ansible. Sometimes, it also means that a developer may slip into sysadmin-land from the other side. There is actually a need for this sort of experience, so it has become a job title, to the detriment of whatever the original idea was.

I've worked with Agile and Kanban and DevOps. My assessment of all of those is that they can all work, but only if everyone is on the same page and agrees to work in that way without coercion. That means that the success that one shop has can vary wildly from the success of others. If you have people who are cynical about these processes or try to evade them at important positions, they become bastardized and they don't work because your shop simply is not following the core practices of the methodology.

Ultimately, as I point out to people, Agile is cool if your team likes it and knows how to implement it, but looking down on "waterfall" or suggesting that it is passe is stupid. So-called waterfall got us to the Moon, and built most of the tools that make up the groundwork of what we use today. Ultimately it is about having a consistent, well thought out management strategy, getting buy-in from everyone and sticking to it.

It is far more important for your team to willingly embrace whatever reasonable methodology you are using than it is to find a methodology that promises results and try to force the team into that mold.

People have done research on things like Agile or Kanban, and they work, but they aren't magic words that suddenly make you more productive. Unproductive teams who fail to actually embrace those methodologies will continue to be unproductive. Highly productive teams would probably see no advantage because they already know their business and really should only implement something like that in response to specific difficulties they experience, and then, only with sincere buy-in.

Of course, self-deception is a problem as well. Some people believe that they are more productive than they are. Some people believe a process isn't working when it is. The only way to implement a development/operations methodology is to have sane and practical goals you are trying to reach and then measure your success against those goals. And by sane and practical goals, I don't mean "lines of code", I mean some measure of actual tested, ready-to-ship features that you are delivering, usually aligned with business objectives.

Re:Can anyone keep up all these bullshits?

[tnk1]

Software covers too much ground for there to be "one true way", or even really for there to be a need for it.

What is needed is definitions for specific types of software, like mission critical health care systems or airplane software. And to some extent, that already exists. The software in an airplane is not usually going to be buggy and is probably already produced in a manner which rivals the processes that other engineers use for things like building the body of the plane or the wiring.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

No, not as much in real engineering disciplines, because they have best practices. This is nearly the complete opposite of software development.

And occasionally, there's projects that require PE's. Management doesn't much mess with those guys.

Re:Can anyone keep up all these bullshits?

[gweihir]

Indeed. These hypes live on the mistaken belief that you can get great value out of mediocre and relatively cheap people by just using the right magic development process. That does not work and never will. It is just another manifestation of the greed and stupidity so prevalent in society today.

The fascinating thing is that even the Scrum manifesto says "Individuals and interactions over processes and tools" in first place. A warning that this is only a tool and will not magically make people perform much better, does not get much more explicit. Yet it seems most people doing Scrum completely miss that one.

Re:Can anyone keep up all these bullshits?

[gweihir]

Unfortunately, how much planning you need to be able to "do" well afterwards depends on the person. I routinely see systems that are completely screwed up because of the lack of planning. They are slow, impossible to maintain, insecure and often do not even fulfill the design requirements. At the same time, they are impossible to replace because there is no specification. Having such systems is worse than having nothing.

Personally, I find that depending on project, I need between 10% and 50% of overall time for planning, or rather fro understanding what problem I am solving. That has worked very well so far for me.

Re:Can anyone keep up all these bullshits?

[tnk1]

Half-Life 3, as far as I can tell, is languishing at Valve because no one wants to work on it. My understanding is that the general policy is that Valve employees work on projects that interest them, and a team has not formed that is interested in doing HL3. I do not believe it has much to do with their coding process.

While there may be some collateral they have produced for it, I don't actually believe Valve has ever actually started working on HL3, so it isn't a matter of them being behind schedule.

Oddly, I don't know how that policy works, because clearly, the company can't really function if they get bored with projects and don't want to work on them any more. Presumably, once they accept an idea, they're required to finish what they start. The hype around HL3 probably means that the people who might be on that team would need to be good and ready to start down that road. Perhaps they were waiting for the Source 2 engine to come out (which happened just this year).

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

It depends what is meant by devops.

It means that whereas before you had to pay both an operator and a programmer, you can lay off one of them and make the survivor do both jobs. 21st Century business logic!

No, it doesn't. DevOps done right requires someone who can see the Big Picture on both sides of the development/operations fence and how to best integrate everything in a constantly-changing environment.

But try and convince the bean counters that.

Re:Can anyone keep up all these bullshits?

[Thelasko]

There are so many methodologies out there. I discovered a new one the other day: "kanban".

Sounds like Toyota's manufacturing jargon is making its way into the programming world. Toyota jargon has been popular in manufacturing since The Toyota Way came out. Ever since then, a bunch of Japanese rooted words started flying around manufacturing plants. If they are implemented correctly, many of those techniques are useful and intuitive. However, managers usually don't implement it correctly.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

It's like saying: we are in the Titanic, we need 10 miles to turn right. Hey, there is an iceberg in front. No, we need 10 miles, so we'll take 10 miles !

And if the Titanic requires 10 miles to turn right, and there's an iceberg right in front that's less than 10 miles away, no amount of hand-waving or bold assertion otherwise is going to change the fact that the Titanic will strike the iceberg, and sink.

If you need more flexibility than Scrum offers, then I'd suggest Kanban is perhaps a better fit:
- Product Owner prioritizes backlog continuously;
- Developers always pull tasks from the top (highest priority end) of the backlog, as defined by Product Owner;
- Limit work in progress in order to reduce cycle time and increase flow through the system.

Kanban has no requirements for standups, sprint definition, etc. However, NOTHING will suffice if you're constantly being told, "stop doing that work, do this instead." If it's interrupts all the way down, and management won't even give you the time to finish your current work in progress before you are thrown onto the next piece, then it doesn't matter what methodology you use - you're doomed to an unending death march which will only end when you quit, or fuck up so bad due to exhaustion that you get fired.

Re:Can anyone keep up all these bullshits?

[gfxguy]

I agree, but as a programmer there's basic aspects that Agile, in theory, is really good at. Using the entire team to break down the project into bite-size chunks and prioritizing them (although, everybody should be doing that anyway), and I also like keeping the client involved because just about every project I've worked on ended up with the client saying "that's not what I wanted," even if they finally admit "OK, that's what I asked for, but it's not what I wanted." Catching things early on helps. I also like the incremental development - you can often get 80% of the way there with 20% of the work, and have something functional for the client, then slowly add that last 20% over time. The client gets something usable faster.

In theory it also shields the developer from managers that want to solve everybody else's problems to make themselves look good - "Hey, gfxguy, can you do [something] for [someone who's not part of the current sprint]?" I am thankfully not in that programming department anymore, but the manager (who pushed us into "agile" after some convention he went to) at that time had a fit in our weekly meeting about why we weren't doing the things he asked us to do, then he specifically looked at me and asked why I didn't do something, and I said "because you didn't make it a task in our system and prioritize it - I was working on my sprint. Do you want us to do agile or not?"

In a one-on-one with the manager, I said "Look, one of the nice things about agile is I get to concentrate on one thing at a time, so am I supposed to do one thing, or multi-task?" And he answered "No, you don't have to multitask, but sometimes you need to do other things, too." No, I'm completely serious.

So there are parts of agile/scrum that fail when everybody is not on board - the manager hears some buzz-words, makes us all go full tilt into scrum, and then wouldn't follow it himself. I also have problems with daily stand ups. We all worked in one open area of cubicles, we could discuss problems and adapt as needed at any time.

Re:Can anyone keep up all these bullshits?

[gfxguy]

I agree... I think scrum works if everyone - especially the manager, is on board. Unfortunately, the reality of the last manager I had was that he pushed us all into scrum after some conference or something... and then would get mad at us for not doing the little side-tasks (favors to other people in the company, mainly) at will because we were in the middle of a sprint.

So, I like it - in theory. It's very hard to get everyone on the same page in practice, though.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

they're really only allowed to interact with developers during sprint planning and a bit during sprint retrospective.

Incorrect. The development team is encouraged to engage in ongoing conversation with the product owner to ensure that their understanding of the business needs matches what the business actually wants. Product owners are also welcome to put YEARS worth of stories into the product backlog, the product backlog is not limited by the team's velocity - only the current sprint's backlog is limited in such a fashion.

What product owners are NOT allowed to do is try to force developers to "put more into the sprint" than developers are comfortable with. That's what the Scrum Master is for, if the developers don't have enough backbone to tell the PO to go pound sand themselves.

Re:Can anyone keep up all these bullshits?

[lgw]

The company I work at now just makes the developer do the ops stuff too. No, we don't bring any sysadmin experience to the job, but we're quite good at automating that ignorance. It works exactly as well as you might expect. I'm amazed at how often some team's "lessons learned" after some disaster are stuff that any mid-career sysadmin would do religiously without really needing to think about it. I'm not clear what advantage this was ever supposed to bring, but it wouldn't surprise me if we found out we were doing "DevOpsJanitorial" next year.

Re:Can anyone keep up all these bullshits?

[wyHunter]

This. If you keep your eye on your business and get on with it, it doesn't matter what name you call your operation. All these bravo sierra names are just an attempt to get something for nothing - "Oh, we're dev ops so now we don't have to manage!"

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Thank you so much for responding. I've had HR shits talk to me about how they know more about programming with their agile shit.

Re: Can anyone keep up all these bullshits?

[Anonymous Coward]

You are wrong. My city is build wrong. They didn't see bicycle boom coming and streets are now too narrow to fix it. The difference in software is that it is often possible to fix mistakes.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Well, in scrum specifically that's what all the rebalancing is about. You ask "does this amount of work make sense for the window we've got (2 weeks)" and if the answer is no, you add/subtract stuff as required.

If a feature needs 3 weeks of functionality to work, then its 3 weeks and fuck the sprint methodology.

When a feature takes 3 weeks, What happens is, it gets sent back to the po to be broken down into smaller parts, so that's 2 weeks gone, then you get the first piece in. so that's 2 weeks. Part 2 comes in, and some asshole on the team whose not an expert in that area and won't be coding it anyway comes in and says: "I can't approve this, I don't understand it completely, can you rework these parts of the story?" So there's another 2 weeks down Then it comes back reworked, and finally, if your're lucky, you have enough points in the sprint to actually get the story in, so the 3 week feature is finally delivered in 8 weeks!

Or the manager/pm could just assign a developer to work on it and work with the PO/BA & QA to just get it done and forget about the process masturbation

Re:Can anyone keep up all these bullshits?

[tnk1]

Having worked at a place kind of like that, I can tell you that ultimately, they considered the functions of the sysadmins and particularly security, to be "in their way", or they simply didn't understand it.

There were some smart guys who worked there, but they thought that they could automate away the job of Operations. I was impressed by some of the things they achieved with automation, but ultimately they didn't understand operating an application or security. It was probably for the best that their app failed, although I admit, it was probably not due to operation failure, but it might have been due to them not actually focusing on good app development, and instead spending all of their time attempting to automate the operation of an application that had an incomplete feature set and a horrendous UX (which they should have been spending their time on, instead of making life of the Operations people miserable).

Sadly, I found out after I left that Ops people were canned en masse when the app failed and went on life support, but they kept the people who made the terrible decisions. They are apparently trying their hand at having developers manage everything for real now. God help them.

Re:Can anyone keep up all these bullshits?

[Etcetera]

Sysadmins need to be part coder these days to do their job properly with automation and flexibility; devs need to be part sysadmin so they can factor performance and stability within sane budgets into their designs.

The thing is, a (good) Sysadmin has *always* needed to be part coder. If you weren't comfortable shell scripting, you weren't being a good Sysadmin. And once you're shell scripting, and maybe doing some perl or python, it's really just a matter of syntax and project scope to go from there.

In short, it's easy to take someone with solid Sysadmin skills and experience and teach them more coding. It's a lot harder to take someone with lots of programming skills and teach them systems administration skills that don't involve programmatically burning and regenerating the machine.

Re: Can anyone keep up all these bullshits?

[Anonymous Coward]

You have no effing idea how to do scrum is all... either your stakeholders want the whole feature or they don't. If you showed them what got done in one sprint (which doesn't need to be 2 weeks, that's just what most teams do today) and they're satisfied, leave it at that. If they're not satisfied, do the other half sprint's worth of work to finish the whole thing. I've been delivering stuff to Prod for the last ~3 years now in 3 week sprints and I can assure you that we released to production each and every time. Sometimes the feature was not fully done and we didn't enable it in prod but the stakeholders saw it and actually readjusted what exactly they wanted once they saw it and we delivered the whole thing in the next sprint. Some stuff took four sprints to finish and no amount of plannibg upfront would've reduced that (vendor documentation lies and they change their systems for other customers that then affects us and crap like that...).

Re: Can anyone keep up all these bullshits?

[lonecrow]

More scaffolding means more jobs and more ways to obfusicate your actual worth to the team.

Re:Can anyone keep up all these bullshits?

[Anonymous Coward]

Pretty sure this is a copy-pasta.

Re:Can anyone keep up all these bullshits?

[bhiestand]

DevOps here. A straight DevOps position in the bay area/silicon valley is higher salary than pure ops or pure dev. And my experience has been that it doesn't displace devs.

It is about a methodology that is largely abused by companies who are trying to "hire devops". But I'd argue good talent should interpret that as hiring an internal consultant / devops evangelist and act accordingly.

You can't code if you're doing sysadmin work, and you can't do sysadmin work if you're coding.

You can't do DevOps if you're not coding, and you can't do DevOps if you're not managing system deployments the same way you're managing code deployments. And you can't do either well at scale without tight integration of the two.

Re:Can anyone keep up all these bullshits?

[sjames]

It's an old story. Good developers on a good team will mix approaches as necessary to get the job done. Managers want to turn it into a procedure that monkeys can use to accomplish the same thing but for pennies on the dollar. It's been 50 years but they still haven't learned two important facts. Pay peanuts, get monkeys and monkeys fling poop.

Devops 101

[Anonymous Coward]

Devops is small changes, signed off quickly by QA, which generates feedback from the users, which results in the next small change and so on.
vs
Major upgrade cycles.

You need to give everything a buzzword name these days, because its competition between buzzwords. Top management will do 'agile' because it shows up top in their Google searches, so incremental development needs a buzzword name too to add a bit of mystique.

Re:Devops 101

[Anonymous Coward]

"Devops is small changes, signed off quickly by QA, which generates feedback from the users, which results in the next small change and so on."

In other words, devops is why we have all these shitty games coming out as Early Access and why we have shit software that releases fully fucking bugged and waits for the community to do all the hard fucking work for them.

Re:Devops 101

[Anonymous Coward]

The problem here is "incremental upgrades" doesn't fit a power point slide, and if you're in a conference discussing your latest brain-fart, you need something that can fit an A4 Powerpoint slide in a decent sized font.

So you see, there is a lot of thinking that goes into these things, its not like we just invent new names for everyday stuff and hold conferences discussing it in Bermuda at company expense. Those new names have to work in 30pt Ariel Black!

Another company was doing their "shortened release cycles as new methodology" and had already renamed "overtime to meet a deadline" as the more Powerpoint friendly "crunch". So we thought, what is the ultimate "short release cycle"? Well, changing the name of the branch from "Nightly Builds" to "Stable Releases" obviously! Then we get a "Stable Release" every night! Genius!
But how do you then fit that into a power point slide?

Nightly Release? No that sounds like a wet dream or old-man-incontinence!
Nightcrunch? Sounded like a snackbar for drunk people.
QuickDev, DevUsers, none of them passed the focus groups.

Finally Devop! Kachink! Bermuda here we come!

Re: Devops 101

[Anonymous Coward]

Oh. You mean Kaizen, the reason Japan's auto industry spanked the U.S. car makers back in the 70's. It took 40 years for somebody to apply that to programming?

Re:Devops 101

[Anonymous Coward]

In other words, it's what's known to end consumers as "eternal beta" and "yet another pesky update".

Word Count

[Anonymous Coward]

"devops" buzzword count: 84

Re:We tried this but accounting killed it because.

[Anonymous Coward]

Janice in accounting don't give a fuck!

Maybe someone should get her some flowers or chocolate.

Re:Sign #10

[Hognoxious]

Thinking that there's a magic methodology that you can follow to the letter without realising that every product, every project and every business is different.

Fad clue #14

[Tablizer]

"You are doing it wrong and need expensive consultants to learn to do it right."

And the #1 Sign You Are Doing It Wrong

[Anonymous Coward]

Your wife is fucking your boss, your co-workers, and your best friend!

So, it is a culture after all

[nerdyalien]

From the article: "Above all, devops is a cultural philosophy".

Looks like it is another buzz word like Agile. Based on my experience, Agile can be "Fragile" when the team is not committed on it. Beyond that, Agile can NOT be applied to a) large projects b) projects with lot of groundwork and c) dev stack that require long compilation/building process. Most Agile/Scrum projects I worked end up falling back to a semi "Waterfall" workflow while still doing some Agile stuff (which I happily coined "ScrumFall" after the penultimate James Bond movie.)

Having said all that, jury is still out there as to whether there is something called DevOps. Only time can tell I suppose. Just my $0.02.

Re:So, it is a culture after all

[pci]

In my work, I'm viewing DevOps as automating the interactions between the Dev and Ops teams. For years the two sides would blame each other for everything and work to prove whatever happened was the other guys fault because they didn't want "root cause" to be assigned to them. With the few projects we have the deployment and configuration tasks completely automated, if an application isn't working then the developers have to own up. If a deployment fails the prerequisites then the ops guys can't hide the fact they didn't complete their tasks on time (regardless of what they tell the PM).

Functional Silos, no one does them better than an old Enterprise IT shop.

Re:So, it is a culture after all

[Anonymous Coward]

agile is just where you take waterfall, change all the terms, add a useless scrum master to the team in additional to your boss and go to lots of bullshit planning meetings where you get to watch the overpaid secretary (project manager) play jira as an rts

Re:So, it is a culture after all

[Cederic]

Oh ffs. STOP conflating Scrum with Agile. Anybody that does that gets promoted to become

the overpaid secretary (project manager) play jira as an rts

Infrastructure as development

[hsthompson69]

DevOps is treating infrastructure as development.

You wouldn't let someone write java code without version controlling it - so version control your packer.io scripts and ansible scripts for building infrastructure.

You wouldn't let someone manually compile their java code instead of using maven - so script and automate everything from your OS build, to your middleware install, to your build/deploy, to your testing.

If you're a testing freak, you can add testing in there too - have automated validation of your OS, middleware, etc, etc.

So, it's quite simple, really - but clearly not well understood.

Re:Infrastructure as development

[TuringTest]

Thanks, that simple description has explained it better than any ambiguous Wikipedia article or newsreel I've seen.

If I have had some mod points left I would have upvoted you instead of replying; this post deserves to be seen.

Re:Infrastructure as development

[Anonymous Coward]

(Posting AC so as not to undo my upmod on GP.) Yeah, I work in a shop that has a DevOps engineer and this is precisely what he does. Our local, dev, stg, and prd environments are versioned and (OK I'm not the DevOps guy) instantiated using Chef and Puppet scripts. He's built us a Jenkins web interface and we can spin up new VMs, deploy to them, change their configurations (including environment settings), etc, etc. It's really handy having abstracted hardware so that it can be instantiated wherever and however.

Re:Infrastructure as development

[Anonymous Coward]

Hell's bells. It took my mod point anyway.

Next time I'll use a different browser/private browsing window. Sheesh.

The wrong way around

[mwvdlee]

"Devops" is what you call developers if you can't afford to have dedicated operational staff.
I just don't see why anybody would actually want a single person to take on conflicting roles.

Re:The wrong way around

[sithlord2]

Where do you get the idea that DevOps equals to one person being both the developer and doing the operational support? DevOps is about bringing the development-people and operations-people closer to together. It's not about eliminating either.

Re:The wrong way around

[blue9steel]

Where do you get the idea that DevOps equals to one person being both the developer and doing the operational support?

Because in most companies that's what the pointy haired bosses think.

Re:Sign #10

[Anonymous Coward]

I thought Sign #10 was that you created a new DevOps department, separate from the still-existent operations personnel, and separate from the still-existent development groups. You know, that department which cares and feeds the "tool maintenance" and accepts "requests" to automate deployment which they can never keep up with, because the are steps behind development, and steps behind operations.

Incompetent people = Chef, Puppet, CFengine...

[Anonymous Coward]

From the article:

If your company bought Chef or Puppet as a cure-all for its devops needs, you're doing devops wrong.

The author hit the nail on the head here. Any company which puts in Chef or Puppet thinking this is a Silver bullet which will solve their lack of change management process and the hack-it-'till-it-works mentality is simply the wrong place for anyone with experience to work at, and the managers and the people who work there are clueless. Stay the hell away from such places, or you will regret being woken up at 02:00 in the morning because people hacked on stuff with Chef or Puppet, rather than doing architecture and system engineering.

(One needs a sound change management process which works hand-in-hand with the configuration management process, and configuration management with OS packages, instead of these ridiculous "policy over configuration" tools like Chef or Puppet.)

Does this mean we're finally done with "agile"?

[Anonymous Coward]

Please tell me that "devops" is the new "it" buzzword so we can bury "agile". Please.

If someone writes a book title "Agile Enterprise Devops" I will punch them.

Re:Does this mean we're finally done with "agile"?

[Attila Dimedici]

You have just given the title of the next IT management best seller.

Are developers really attracted by buzzwords?

[Anonymous Coward]

From the summary: "it can serve as great PR for bringing in great talent to your team"
Really? Do you attract good developers by saying that you practice the latest and greatest buzzword? Anyone with half a brain knows to first of all investigate what the company in question _actually does_ before signing on and secondly, I think most people realize that none of these fancy methodologies are a silver bullet for being a great place to work. You need skilled developers and a management that realizes that these developers can produce good results. Then you can do whatever process you like, but if you don't have those two, you're fucked. So stop selling all these processes to us, we know you want to be consultants and save companies with your buzzwords, but I'd rather you just pissed off and let us work.

"Agile" development is a trap.

[Narcocide]

I'm completely convinced the real long-term purpose of the Scrum/Agile methodologies is simply to further weaken any market competition naive enough to adopt it in the first place.

Sign Zero You're Doing Devops Wrong

[Anonymous Coward]

You're considering Devops in the first place.

1.

[Anonymous Coward]

1. You're doing a thing you call devops.

Re:We tried this but accounting killed it because.

[Anonymous Coward]

If she does not give fucks maybe someone should give her one

WTH is devops?

[Anonymous Coward]

What in hell is devops?

Strikes me as Application Specific

[ThosLives]

Or at least portions of it. Most of this thread seems to be authored by A.C., so it's hard to get a discussion going...

That said: The one concept in the article about "continuously pushing code to production" sounds great, but I think it has serious limitations. Especially when coupled with the "don't be afraid to fail" concept. Perhaps for news aggregating websites or something that is fine, but you don't want to be developing safety-critical software that way.

The things that are useful, perhaps, are the automation aspect, where you write tests first and have code automatically tested whenever it is committed - that part I think is important. I like the hand-wavy bit about "assuming your tests are correct" bit though - that takes significant effort!

But saying that "you're doing it wrong" if you have a slow release process is not helpful; in some cases you absolutely want a slow release process, because those releases must be vetted.

TLDR version: Automation of processes is good, but I have to disagree on "good devops" to requires "continuous release."

Re:Strikes me as Application Specific

[Cederic]

As with most of these things, it's a balance.

Continuous delivery on the home-grown intranet? Sure, go for it. Hell, Facebook do it on their mammoth shitfest.

Continuous delivery to car ECUs? How about continuous delivery to the engine testbed, and keep the fire extinguishers primed.

Even where you're putting a manual authorisation with specific checks and balances in place though, one that authorisation is given the rest should be automated. There's no point having thorough, extensive, durable, repeated and manually reviewed tests for a global payments system if you then let some sysadmin enter a typo while manually deploying it and cost the company $200m.

What is DevOps anyway ?

[Anonymous Coward]

I've always found that the best way to get something right is to first know what it is. Try as I can, I still don't really get what DevOps is supposed to be.

I've read the propaganda, but still I don't see how it departs from simple common sense. DevOps is about the closer collaboration of development and operations. Due to the monadic nature of computing, there has never been a clear line between the two anyway (is writing a script in Bash Dev or Ops ? How about tuning an Apache server to optimize your app ?), so DevOps doesn't really exist, or rather it has always existed as both Dev and Ops.

Remember that "development" and "operations" are HR terms describing what your job looks like to them. We are all programmers underneath those names, and the notion of DevOps is just an acknowledgement of that fact by the powers that be, not a redefinition of our profession.

The boost in productivity observed in "DevOps compliant" companies is thus very simple to explain : when you stop trying to segregate people based on the perceived level of abstraction of their work, individuals are free to span multiple abstraction layers and eliminate most of the previous inter-layer communication costs and cultural differences. Otherwise, it's like you're building a dam and expecting the river to flow more quickly.

In light of that, I'd like to conclude by asking of HR everywhere to let us choose the name of our profession. Giving people meaning is not your job, and we are not grateful when you do it wrong.

Re:What is DevOps anyway ?

[blue9steel]

is writing a script in Bash Dev or Ops ? How about tuning an Apache server to optimize your app ?

Those are both Ops definitely. Writing a system that automatically tunes several hundred Apache servers over time as things evolve, that would be DevOps.

Re:What is DevOps anyway ?

[Jerry Atrick]

I've read the propaganda, but still I don't see how it departs from simple common sense

That would be the 'trusting automated testing enough to push potentially catastrophic updates straight to production' part. Not assigning blame to the dev's fixing the resulting mess might be a necessary concession to getting the job done, no one accepting responsibility for such a testing failure, not acceptable.

For many organisations giving the end user faster updates most of the time is a small benefit compared to the risks involved.

Re:What is DevOps anyway ?

[scamper_22]

I agree with most of what you said, except that organizationally from a business standpoint, unless there is a group for it, it is not being funded.

Yes, most developers have had to do DevOps at some point.
I've tuned databases, written scripts to automate environments and databases...

It really is a job in itself in any complex environment. It took me out of my comfort zone as I got into managing databases, replications, restores, virtual machines...

There is definitely a need for a develop with operations focus. Hence DevOps. Like I said, unless there is a group/title for it, business is clueless about it.

So it is a good thing.

Re:What is DevOps anyway ?

[Cederic]

Any good software engineer has already helped Ops through automation.
Any good Ops person has already given a developer a raft of suggestions on how the shit they handed over could be improved.
DevOps merely points out that this is actually a good thing, and seek to do it instead of being asked.

No funding required. Just do your job like a professional, not a fuckwit.

The hipsters are the problem

[Gazzonyx]

You're not old or wrong. The hipsters just discovered UNIX pipes/sockets and decided that they should give them a trendy name... I shit you not, meet etcd (to be fair, it's pipes with a few extras, but nothing worthy of a name because I guarantee this has been done in the last 40 years once or twice). https://www.youtube.com/watch?...

This is actually the problem I have with Design Patterns - not them in and of themselves; I don't think they needed names, but I'm okay with them having names. I came to figure out Inversion of Control in college before I knew it was a thing. Having common terminology doesn't hurt, but lately it's gone too far. The problem is that someone, somewhere decided that this idea could apply to EVERYTHING. Then we get Enterprise Design Patterns (hello, Spring, OSGI, Blueprints, etc. - each a very specific thing that is so incredibly abstract as if to mock the very idea of naming conventions), Enterprise Cloud Design Patterns, etc. An "Enterprise Cloud Design Pattern" used to be called a topology and they could be expressed in terms of their layout (star, bus, hub and spoke, etc) in terms everyone understood and was comfortable with. Adding virtual machines and "cloud" and load balancers doesn't change the fact that it's a star topology with redundant load balancers in front of it. You don't need a specific term for that.

Now, allow me to rant for a second... Related to the point, the worst quality software I've seen lately describes what it does in these terms. For instance, if you weren't familiar with J2EE, would you ever know what Karaf ( http://karaf.apache.org/ ) is? Don't bother looking for answers in the documentation, because it's sparse and often incorrect when not hand-wavy. I spent a day trying to just get the web interface up to launch something in Karaf (since they recommend that) only to find that "just launch the thing and then open your browser" isn't the way you launch something and you can't access it from your browser. I couldn't get to step two of the documentation that I had to look in Google caches for because their own links to the 2.4 documentation are dead. That's the version that the current version of OpenNMS ships, and they actually changed the command "features:xyz" to "feature:xyz" just so the only documentation where they got their links right is effectively useless until you figure out why nothing works.

Marketing

[Anonymous Coward]

Is DevOps a coined term used by companies to market software and hardware to help you company do work?

is this a marketing ploy?

Re:Sign #10

[Gazzonyx]

Apropos, my boy Freddy Brooks : https://en.wikipedia.org/wiki/...

The first sign you're doing it wrong ---

[QuietLagoon]

Using the word "devops"

disagree with #5 an #6

[buddyglass]

Re: #5, sometimes a failure is so egregious it's worth firing someone over. This should be measured not by the severity of what happened, though, but the dumbness or carelessness of the mistake that allowed it to happen.

Re: #6, sometimes it's right to assign blame. That doesn't mean you rake that person over the coals, but at the very least that person (and whoever has the authority to fire or promote him or her) should understand who is to blame.

Re:disagree with #5 an #6

[gweihir]

ReRe: #5, but that would mean you have to fire _management_! Because they put somebody into a position where they were in over their head (I see that all the time...) and set them up to fail. Nothing more stupid than doing that. (Of course you need to fire the incompetent developer/tester/etc. as well.)

ReRe: #6, this one is very tricky. Finger pointing usually does not result in any clear picture and quite often the people actually responsible manage to fly under the radar. While not assigning blame is a bad solution, assigning it wrongly is infinitely worse.

Re:disagree with #5 an #6

[Cederic]

I've known some very good managers who explicitly state that they will not ever fire anybody for making a mistake.

Make it twice however..

Even there though, root cause analysis. Is the developer lazy, or is this just within the reasonable bounds of human limitations and best addressed through a change in process, an authorisation, an automated test, additional training?
Are Ops incompetent or making rational decisions that have bad outcomes because there are no good options available, focussing on a different issue that has significantly high impact, being ordered to prioritise the wrong things?

Nobody is intentionally dumb, so look beyond the obvious and sometimes, encourage them to find another career. Sweeping the streets, changing adult nappies at a care home, something they're actually capable of.

The problem with prototypes

[Anonymous Coward]

is management then take the prototype and implement it to get it out on time. The prototype should be discarded. EVERY TIME. Because you learn something when writing the prototype that inevitably leads to, some time down the line, "If I were to write this again, I wouldn't have started here".

Sometimes it's as basic as the word description of the language insists that you can do something (read up on char** string arrays. reads like you can just make it up of a load of char*, but the compiler cannot manage that, because it cannot know to concatenate them in a ragged string, and there's no way to tell it beforehand. So you have to reserve an array of char*, reserve a block for a char** or use a linked list of char*, which are all different solutions that you wouldn't know until you wrote your first C program using string arrays), but sometimes, especially in OOP, it's that some idetic feature you made into an object convolutes the object graph and you need to build "port forwarding" into your objects so that other things can read the state or modify the contents of the object when inside another object. And redesigning it differently, maybe changing the heirachy, will lead to a stranger object list, but a simpler object graph, and therefore more "black box" that is the reason for OOP.

But if it works, you will be pressured to keep it and roll it out, or at best, tidy it up as it is, and fix it "later".

Re:The problem with prototypes

[gweihir]

Not necessarily. A prototype can be a viable implementation if it is done well. Of course, only people really good at this (and hence expensive) can do that.

Re:The problem with prototypes

[barbariccow]

What are you talking about char**? It's a pointer to a bunch of pointers. You malloc the first with the number of strings you want, you malloc each string with the length of that individual string, and copy in the data. This is all handled by libc anyway, unless you use a custom malloc, and has zero to do with the compiler.

Re:The problem with prototypes

[mfearby]

I have no idea what the difference between a char* and a char** has to do with this discussion. In any case, none of the languages I use have pointers like that, so I'm saved from all that nonsense :-)

What DevOps really means

[plopez]

You can have the Devs do Ops and so you don't need to hire any of those pesky Ops people. At least that is how managers see it. Saves time! Saves money! Agile! Buzzword compliant!

Basically as I read up on DevOps I found I had been using it for years. Except I called it "running a professional software development shop where everyone works together to meet goals". Of course "DevOps" looks better on a book title or as the title of a blog post.

Re:What DevOps really means

[Cederic]

Except I called it "running a professional software development shop where everyone works together to meet goals"

That'll never work! Why, if it did everybody would be doing it.

To be fair, I'd settle for people even bloody trying..

Where I work

[kilodelta]

We violate half of the seven items on the list. Oh well.

DevOps$ rm -rf QADevOps

[Anonymous Coward]

A devops guy with deleted (with prejudice) a Jenkins install our QA team had setup to run tests the way they wanted to rather than the way he allowed. Now he DevOps for GM.

But Isn't It Also True that...

[careysub]

But in truth, many companies — and technical recruiters — that are proclaiming their devotion to [ANYTHING AT ALL] from the hilltops aren't really [ANYTHING AT ALL] organizations."

Sign 1

[allo]

You're doing devops.

Natural result of #4

[pavon]

Number 5 are corollaries to number 4:

At its heart, the agile methodology consists of releasing small changes as often as possible ... It is about defining what is considered "production ready," representing that with a set of automated tests, and trusting that the tests written correctly define what it means for code to be "production ready." ...

For the true devops rock stars, it's also about taking that code and sending it directly to production through continuous deployment. If your company allows developers to check in code that goes through automated pre-check-in tests, gets handed over to another set of tests to ensure that the code is ready for production, then goes live on your production servers if deemed ready automatically, then you know you've achieved devops greatness.

If your organization really believes that automated tests can find all show-stopper bugs, and that absolutely no man-in-the-loop soak testing is needed to find unexpected problems, then you are guaranteed to have these failures in ops rather than dev. At that point, you are either explicitly accept that you are treating your users/customers as alpha testers, or the blame is on whoever adopted that QA policy, not the person who introduced the bug.