alt Hacker NewsScrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Replies
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
A dev can very much enjoy learning new skills without feeling any desire for the pressure and burden of having to deal with ops.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.