> Personally I think DevOps is like religion

As long as no-one is knocking on my door asking if I have five minutes to discuss Agile development methodologies.

I could reasonably defend most of what people attach to the "DevOps" buzzword as sane practices most of us were already doing before the hoopla.

Agile (with a capital A) is the absolute worst thing that has ever happened to the software industry. Kill off that cult and you can DevOps my work with containerized OWASP Gitflows until the end of days for all I care.

Snark aside, Dave Thomas makes a compelling argument for trying to choose terms that are as hard as possible for others to co-opt for selling snake oil (anecdotally, I encounter people on a weekly basis who are self-described Agile or DevOps experts, but have no technical background whatsoever).

I once worked at a place full of Agile cultists, including a bunch of "certified" "coaches." They spent about 1/4th of the time in planning meetings, retros, grooming sessions, sending emails about updating percentage complete on jira tickets, etc.

They made some of the dumbest technical decisions I have ever seen, were perpetually rewriting things, changing core APIs, breaking other parts of the system. The stuff barely worked, and this was after 5 years and dozens and dozens of developers.

The place was so dysfunctional, you could not even create your own branch in source control. You had to request it from the IT group that maintained the "enterprise" SCM server. The IT groups were doing their own form of Agile, so these requests could take weeks.

Truly awful.

Heh centralized teams to request something as simple as a branch to commit code... or to deploy a feature, and not at scale or anything, where “services” are a simple CRUD API with like 4 people who are customers.

Bloated IT organizations. Reminds me of working in the energy industry. Made up jobs, unmotivated workers, and incompetent management including the CTO. C level exec magazines says to literally eat shit? Here, let’s eat warm turds everyone.

Seems to me that place would have been dysfunctional with or without their dysfunctional form of ”agile”.

You are correct. The Agile-esque nature of the place was just added icing on the cake, so to speak.

I've worked in several places that each had their own unique snowflake take on "Agile".

With Agile being constant, the experiences were wildly different between them.

The key variable to whether they were dysfunctional or not wasn't Agile. It was the quality of the people in management.

My pet peeve with agile is it is so rigid at most places. Our team had a bug a while back. We all failed to understand something until it was getting QA'd. We told the PO that we'd need at least part of a sprint to fix it and asked if we could get that prioritized in the next sprint. You would have thought we'd asked to kill someone. We wasted a couple hours debating why it couldn't be finished in this the last day of the sprint. WTF?

This is literally the opposite of the agile manifesto and the original intent and the origins from Lean manufacturing.

Take a look at original agile folks who discuss this extensively on twitter.

Look at John Cutler's incredible blog posts: https://medium.com/@johnpcutler

The "Agile" most people complain about is the same thing we had before "Agile" came. You've got 2 broad camps: people who really want to do adhoc development and would like an industry accepted word to call doing whatever-the-heck-I-feel-like. The other side are the people who, having risen to a position of influence are desperately trying to add value, even though they don't actually do anything that results in code being written.

In the former camp, the people tend to like "Agile" because of the doctrine of writing code over doing planning. Often you will find PGMs/PMs who will write a story like "Make the site awesome!" with no other details. They usually want an estimate of how long that's going to take, but will refuse to add any more details -- because that's over-complicating the issue. They really just want to take credit for anything good that happened and punish people for anything bad that happened, all while doing absolutely no work. Usually they are actually deluded enough to think that their role is vital.

In the latter camp, usually there is a feeling that the programmers are stupid and this is why everything is in a complete mess. In order to fix things, they want to take control over everything and throw things over the wall at the programmers. Often the people in these camps used to be programmers (or may still think of themselves as programmers) and have always thought, "If only I could make everyone do what I want, then I can fix all the problems". So they spend their days dictating what everyone will do. It gets even more fun when similar people band together to form elite troops of specifiers -- that's where you get the endless meetings.

We've had this since programming in groups began. This is nothing to do with Agile. It wasn't any better at all before Agile. After Agile was introduced, nothing changed at all except now these guys have another name to incorrectly describe what they are doing.

My biggest problem with Agile is that it says nothing at all about how to accomplish the stated goals. That's why it is so attractive to people who don't have a useful methodology for producing software.

Do I want to continuously deliver software? Tick. Do I welcome changes to requirements? Tick. Do I want to deliver software frequently? Tick. Do I want business people working with software developers? Tick. Do I want motivated developers? Tick. Do I want to have face-to-face conversations? Tick. Do I want working software? Tick. Do I want to sustain a constant pace indefinitely? Tick. Do I want excellent software and design? Tick. Do I want simplicity? Tick. Do I want self organising teams (as long as "self" means myself)? Tick. Do I want the team to tune itself to get better? Tick.

Wow! I'm Agile! Whoo hoo! How do I accomplish the above? To quote someone I worked with in a previous job: "Most of this stuff is common sense. We're all the best in the industry and so this should be second nature to us. If anyone can't do these things then they really don't belong on this team". Now that's a strategy!

Mark my words: within the next 10 years there will be a new word for people to rally behind. At first it will make sense and some people will do cool things. But then the people who want to do nothing and the people who want to force others to do their bidding will grab the word and crush any meaning it ever had.

It’s not really common sense, and the agile I know of says quite a lot about how to accomplish goals, if your goal is “delivering quality software products/services”.

There also is bullshit Agile of course, which you describe well, but that’s no different from any old software process that’s more bureaucracy than content.

My point is that the cynicism ignores actual differences in practice and process that can have an order of magnitude impact on performance, and its not always “obvious” for smart people to adopt such practices.

Consider Lean manufacturing: the Japanese thought it was just a common sense extrapolation of Henry Ford’s system of organization. It still took decades for the US auto manufacturers (including Ford!) to wrap their heads around it.

There were plenty of crooks and charlatans in that field too. It didn’t negate the importance of what Toyota had figured out.

Brutal. Accurately brutal.

What’s your preferred methodology to Agile? Waterfall?

I quite like this as a good resource:

https://agilemanifesto.org/.

Whatever gets the work done and doesn't cause unnecessary burdens while adding no measurable value is good with me at this point.

I'd make do with anything but Agile, which needs to be shot. Out of a cannon. Into the Sun.

Genuinely curious, what is it that you don’t like about Agile? I mean, the concept, the processes? The lack of something or too much of something?

Not the parent, but I agree fully with their point - agile is good; but there is a difference between "agile" and "Agile".

Especially in the enterprise world, agile has been overran by worthless certifications and so-called "Agile" consultants/experts, who broadly fall into 1 of 2 groups: project managers looking to cash in, and technically inept "senior developers" looking to cash in by turning consultant.

Every one of which has their own incredibly dogmatic view of what it means to be Agile. And all of whom are skilled bullshit artists, adept at gaining the ear of upper management, proficienct at indoctrinating them into "the one true way"TM. Every one proficient at making developers miserable - all while charging exorbitant fees, and leaving just in time so management is convinced the failures are down to the heathen devs not following The Agile Way.

Standups where you literally have to stand up (simultaneously, even if spread across 3 continents and numerous time zones) and invariably go on for an hour, constant complaints (and of course meetings) about stories not finished before the sprint ends, endless meetings about the line on the bastard burndown chart, backlog refinements that last days or even weeks (invariably followed by story refinements that last days), telling the devs "decisions are up to the team... but you will choose my way", meaningless identikit retrospectives when the devs just want out so they can actually ship something...

Honestly, I'm not sure whether these "consultants" actually believe the dogmatic, quasi-religious snake-oil BS they are selling, or they know full well, but know just as well how much money they make from it.

All I know, is these people give agile a bad reputation, and bring absolute misery to many a developer.

GordonS gets it.

This is true. Not long ago (about six months) a project I was working on was assigned a scrum-master (tip: You can just be the person saying "any blockers?" and "next". You don't need to be master of anything.)

Genuinely nice person, it's anecdotal, but just making it clear I'm not bashing them. Regardless, after a stand-up in the very first week they just volunteered that they had no technical background whatsoever, and couldn't write a line of code. They were at the same time actively making architecture decisions outside of the stand-ups and relaying this to the P/O.

It was a nightmare.

The above is right, Agile (with a capital A) has become little more than a way for non-technical people to have lucrative careers in software by destroying the otherwise promising careers of technical people in software.

Appreciate you explaining this point further, I didn’t realise there was a difference between ‘agile’ vs ‘Agile’ and the only other methodology I had heard of was waterfall which also seems to be universally disliked.

"Agile" is just an instance of "agile" which is an abstract concept. Hence you can't actually do "agile". Therefore every form of agile you see is "Agile" and they're quote "doing agile wrong".

Read the manifesto. It literally says handful of almost completely meaningless, unimplementable things.

Any attempt to actually take that and turn it into something is destined to be sharply divorced from reality.

But the real fun comes when you do "white water rafting" style development. This is when there is all the ceremony of "Agile" (read: a "fast paced environment") with all the planning of waterfall and absolutely everything is top priority. You and your coworkers are constantly thrown around trying not to smash into rocks or capsize the boat, meanwhile being pulled violent in every direction. Somehow you continue to make your way down the river eventually with fewer and fewer co-workers as she casualties mount.

Fun times.

The actual methodology is completely irrelevant. Working under terrible management is terrible. Working under terrific management is terrific.

You should read the original waterfall paper as it is basically agile in spirit: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

Waterfall had its place in military and aerospace, where the requirements and API were well-defined, and to a lesser extent in life-critical medical systems development.

But in even those cases, it was largely replaced by Spiral, which is similar to agile and pre-dates it.

Edit: Spiral is like going down the Waterfall two or more times. Similar to agile, but formally documented, with management and customer sign-off up the line, and with a much longer cycle time.

My experience of that which has been called 'agile' is that it's an excuse by programmers not to do the boring stuff, so they can got straight into the coding.

Not to plan, or even think too much, definitely not to document (sometimes not write anything down at all), often not to test except in a token form and sometimes not even that.

Is that agile? That's how 'agile' has been done where I work anyway. Maybe I've been unlucky but 'agile' like that is a loathsome, unprofessional practice that can't produce good results.

Yes, I understand. While I’ve never only attributed that to Agile alone, but also this sort of brogrammer-code-is-the-real-product, it sometimes feels like a maturing industry sort of rolled back into its teenage years. Diagrams? Solution models (up front thinking)? Document for future reference? Nah, we don’t want to do that.

It’s sad. Just recently had an experience like this with developers I manage. I do loathe the brogrammer culture more than anything...

A significant chunk of software is a dead simple one off and does not need much in the way of design or maintenance. At the other end you have software that risks human lives and or billions in damages.

Picking the right process for where each project fits on that continuum is surprisingly difficult. Cowboy coding can be anything from a horrific idea to the most efficient setup, unfortunately people are rarely flexible enough to know the difference.

That’s why I always push the message that we choose the right amount of bureaucracy for the task at hand. Simple change / feature? No need to make a lot of documents for that? Fluffy idea that several people needs to work on? We need some mocks, diagrams and take requirements from client.

I think that’s a healthy way of doing it, but sadly many almost have to be pushed to do it, even with bigger things.

> feels like a maturing industry sort of rolled back into its teenage years

Beautiful description! That is so on the nail.

There are cult-like tendencies in part of the agile community. I don't see it in the teams I have worked in, but in forums on LinkedIn, by those that see their career as agile specialists, experts in coaching the true way to perform agile software development. Many of them see themselves as catalysts, and that they with clever questioning will make teams grow. They don't themselves want to have a delivery responsibility, but they want to stand on the sidelines and "coach".

That I can understand and I’ve seen that too. And now Scaled Agile Framework is coming in hot as the enterprise version.

I’m actually proud of the parts of agile we work with, which primarily enables us to react changing needs and priorities quickly (unlike heavy waterfall).

After 22+ years in the industry I’ve come to realize that any new concept or concept that gets traction (CQRS, Event storming, AI) will produce a religious following. It’s kinda sad, because causes as lot of noise and friction.

Shape Up sounds interesting, particularly for remote-only teams in non-massive companies. Haven't tried it but it sounds interesting.

https://basecamp.com/shapeup

agile, lowercase a, is not bad.

Right, I didn’t understand there was a difference. Thanks for that, I’ll look into it.

It is not a formal difference, but agile has evolved into an industry itself, with certification ladders and gurus. So on one hand you have the one page agile maniefesto, on the other people who make their living on preaching how teams should work, shouting from the sidelines.

my bar for "DevOps" on my (SaaS) team is that the engineers responsible for the platform the product runs on are involved in the discussions about the product we build.

everything that comes after that: pipelines, testing, release engineering, migrations, post-mortems, whatever -- it's all a result of your infrastructure engineers having a stake in the thing your company is building. I have yet to see a definition of DevOps that invoked some sort of tech stack that made any sense to me. the processes and tools emerge from a cooperation between stakeholders and a shared responsibility for the delivered product.

DevOps is the channel in slack I check when my code didn't update. That the directs me to somewhere else where I just sort of randomly click things until it works or gets worse.

But yeah I'm with you on the wild definitions, it can be anything from some overnight IT grunt, to something far more respected and involved depending on how the company did things.

> But I wish companies would go deeper than "DevOps" when putting up job posting requirements.

I am not sure this problem is limited to DevOps. Once I applied for a job thinking I understood the job description. During the interview, I had to find out that they put only half the job in the description (the good parts).

Afterward, I took a look on the job description again asking myself if I misinterpreted the description but came to the conclusion that they just didn't want to write about the downsides of the job (not even in management speak like 'You love a challenge?').

Firms don't want you to know it, but they are struggling to hire competent IT professionals to an extreme degree. Recruiters are being regularly ghosted (like they used to do to candidates) and turn over is increasing. That's why you see them resulting to tricks like this. One thing to keep in mind is that most managers working today cut their teeth when unemployment was at 10% or so, as such they really only know about bait and switch tactics and the stick. Carrots aren't something that really fits into their mental model.

In short, to anyone reading this. Now is the time to make your move.

> Recruiters are being regularly ghosted (like they used to do to candidates)

Not sure if this is the same thing (with "ghosted"), but I have 3 rock-bottom criteria before I'll respond to a recruiter's email:

* Send to the email on my resume, not my personal one.

* Show that they've read (or at least keyword-matched) my resume.

* Something in the job description should at least be vaguely enticing, such as a technology I have on my resume. The same thing can hit both points 2 and 3, the depending on how the email is structured.

In nearly 10 years, a grand total of one recruiter got all these points. Half of them failed on the first one.

> Some companies think DevOps means having an automated pipeline for building, testing, and shipping code.

This seems to be the most common interpretation, but I largely agree with you on no hard and fast rule here.

It's because it ultimately does mean that.

I mean, sure, if we're being pedantic about it, devops is about the silos coming closer together, cross learning, culture and what have you, etc.

But the outcome of that the cross learning is pretty much release engineering, that includes the above and the products giving more data for helping run them, and simplicity leading to being easier to fix, and do the aforementioned things.

I also think we should just get over it and probably just adopt SRE, Release Engineer and Product. Not because I <3 google, just because the split makes a tad bit more sense.

> Others think it means making developers do DBA / SysAdmin work.

I've been in that spot many times. In my last job, I did engineering (networking, server, etc) / support for 7 data centers. We started to support of 3rd party "cloud" products, and then they dropped the DCs they gave me the title of DevOps Engineer IV. When they did that, I didn't have any Dev or Ops responsibilities.

People can’t agree what devops is, sure. But I feel like it’s extremely easy to tell what devops isn’t. If you don’t have any confidence in your releases before you’ve done extensive ad-hoc manual probing you aren’t doing devops. If your using oracle and Delphi even though none of the developers would chose it because “that’s what management decided” you are not doing devops.

The rest of the story is just about the tooling and management decisions that support getting out of those pits. You use micro services because it allows developers to use whichever tools they want as long as they solve the task. You use automated tests and deployment pipelines so the team and organizational procedure to be confident in releases shifts from becoming “talk to Tom and get his blessing after he’s spend a week probing everything” to “well if it passed all tests and deployed then it’s a go.

It’s not like the technical issues suddenly disappear. You need to set up your tests to a level where you are confident in the pipeline. You still need to spend the time and resources making sure your microservice infrastructure is working.

But at the end of it you’ve removed the power of the gits who where previously controlling the techs allowed and the releases, and your letting teams move forwards through proving their work rather than constant audiences with individuals who are gatekeepers because they spend 20 years in the same organization and feel that everything invented in the last decade is scary.

> If your using oracle and Delphi even though none of the developers would chose it because “that’s what management decided” you are not doing devops.

What does that have to do with DevOps? Clearly that's not an ideal situation, but that has nothing to do with CI/CD pipelines, developers handling operations work, etc.

I think they're driving at "management is dictating technical decisions"; many people view DevOps as a cultural shift (if not a mindset) that includes empowering developers.

Interestingly, your question of illustrative of the "DevOps has no clear, standard definition" problem.

That brings to mind another interesting point--even if you can tell what DevOps isn't, so much of a "DevOps" role at any particular company is dependent on the technologies that the company has adopted. I imagine DevOps looks wildly different at a company that deploys a monolith to an EC2 autoscaling group versus the company that deploys microservices to Kubernetes. Similarly, whether you use a monorepo or a multirepo. These sorts of concerns drive virtually everything about the DevOps role--the entire structure of the CI/CD pipeline, the strategies for fast rollbacks, the local developer tooling, how much time you spend at which layer (e.g., if you deploy to EC2, you're probably spending a good chunk of upfront time configuring log exfiltration and process management versus something like Fargate). And this says nothing about which cloud provider you're familiar with, or the cultural concerns (one company's DevOps might be chartered with driving cultural change while another's is taking strict orders from management).

Given how large the gap between any two given DevOps positions, I wonder how valuable it is to have "DevOps" job reqs or conferences or other "DevOps" things.