[talk] OpsMops Halted (probably OT but tangentially related to April 3 talk)

[Raul Cuza]

(1) https://threadreaderapp.com/thread/1091710068234641408.html
(2) https://news.ycombinator.com/item?id=18716628
(3) https://techbeacon.com/devops/how-create-devops-testing-culture-3-keys-success

# tl;dr
(1) is the announcement that Michael DeHaan is stopping development of
OpsMop only after a few months of working on it. This is the same
developer who wrote Ansible.

(2) is a small selection of the reaction to DeHaan's announcement
about OpsMop and proof that his reasons for stopping development have
merit. (More about the reasons for his stopping below.)

(3) is a tech BS jargon heavy article that shows that there are other
people who agree with DeHaan but have their head too far up their
chosen solution to see the solution to their misery.

# Why am I sharing this?
I miss the (nonexistent?) tech era when the hardware, operating system
and application were all crafted to work together by the same team;
choices were optimized for the people, problem and situation. Building
out a tech solution today involves so many layers piled on each other
that it is a miserable experience troubleshooting through all the
garbage code. Maybe if I had some choice over which open source OS I
had to run on other people's hardware, I would not sound like a grumpy
old sysadmin right now.

I sympathize with DeHaan who wishes DevOps didn't mean DSL writing
SysAdmins who work only on ops and automation. I also don't want to
fall into his trap of having to be "feed by interaction" which is
ultimately why he stopped work on OpsMop. If a project scratches an
itch, then why not work on it whether you are going to be on the cover
of PC Magazine or not? But then again, I am not a tech artist, so
maybe I don't understand.

Finally, Adam Auerbach in "How to Create a a DevOps Testing Culture"
essentially agrees with DeHaan, but for the sake of DevOps Culture™
which misses the point.

"""
*Successful DevOps adoption* requires more than just automation across
the software development lifecycle; you also must change the way your
team is organized, the way you work, and the expectations you have for
people on your team. It means having engineers in all roles and
removing the dependency on enterprise IT teams—such as operations or
security testing—from getting features out the door.
""" (my emphasis)

The point isn't DevOps adoption, but building the effective tech
solution efficiently. I do agree that all the Go/No Go people should
be on the same team and working together. Having outside people who
don't take the time to understand the technology but can stop its
deployment is a sad situation. Gatekeepers are feudal "Expert Class"
that should be democratized by spreading the skill around evenly (i.e.
turn their expertise into testing code and engineer can read!).

Raúl "really needs to stop procrastinating" Cuza

p.s. Maybe I should be more forgiving as in my day I wielded tech
jargon like I had found the Holy Grail. But I'm older than that now;
so meh.