Comment by kelnos | Hacker News Reader

Comment by kelnos | Hacker News Reader

Parent Full thread

I don't necessarily think this is a bad thing.

I "enjoy" doing my own ops part of the job because it often feels like I have fewer roadblocks in my way. I build my stuff (or fix my stuff), test it, build some deployable artifact, and deploy it. I do it all on my own schedule, immediately when I'm ready to do each step, and I don't have to wait on someone else.

But if I'm being honest, I have spent so so so many hours dealing with "ops bullshit", that I probably would have been more productive overall (perhaps worse latency, but better throughput) if I could have just focused on the build/fix and test parts, and kicked the final result over to another team to deal with deployment concerns.

I'm still not sure which is better. Maybe neither is objectively better, and it depends on the person and organization. Maybe have separate teams, but make your devs do a tour of duty through the ops team every now and then so they understand why the ops people get mad at them from time to time. And vice versa.

Anyway, I don't buy the CYA/hand-wavy reasons in the article guessing why DevOps is supposedly dying. I suspect it's for the same reason Agile turned out to be a drag on so many developers: people cargo cult and don't really understand why they're doing a particular thing, so they never adapt it properly to their environment.

So the managers bring in consultants, and the consultants just roll out their cookie cutter solution, with their favorite issue tracker, CI/CD product, deployment system, etc., without really understanding the org's needs.

Then the managers get upset, and we get articles like this.

Exactly, dunno what to call it ... but every new concept starts out good, gets crazier and crazier and sometimes it may become good again, but most of the time it just devolves into more crazy.

In one of the orgs I worked, ther was a team which worked on the basic devops framework which the application teams could use to then configure their resources. It was a very sane approach.

Nah, it works like this:

- we get a new methodology by remarkable ppl who can make it work really well

- some managers/consultants decide to modify it, twist it, with reasoning that „its hard to do well”

- the initial thing is lost in translation, twisted and bent to sell better by consultants or fit nonfunctional corps

Agile, DevOps, Software Craftsmanship, testing methodologies all did share the same fate.

Issue is that remarkable ppl are few and far in between. Medicore and subpar ppl are plenty.

Yup, it's a cycle. Take "agile", for example.

Kent Beck (of "Extreme Programming" aka "XP" fame) is a joy to read. He thinks really deeply about software, and takes things to interesting extremes. But he's very pragmatic about it.

Then XP becomes the Agile Manifesto. At this point, we're getting a bit silly but it's still an interesting idea.

Then we start talking about paid "agile" consultants teaching big companies. Maybe it's still better than the alternative. And some of the best ideas, like unit testing, seep into the culture. (80s and 90s project planning and testing could be terrible in ways any undergrad could fix today.)

And then, eventually, we have so-called "Scrum" being run by someone who learned about it third hand through a game of telephone. Every truly successful revolution lives long enough to become a gross and broken status quo. And so the cycle repeats.

That said, Kent Beck is still writing, and he's still delightful to read. I knew his favorite themes 20 years ago, but sometimes I pick up his stuff and find a clever new insight.

Disagree on point 2. It goes straight from successful for one team, to lost in translation. It's not managers' fault that it gets lost- it's just what happens when teams try to adopt something that worked well for one team, without the implicit context.

Reply on news.ycombinator.com