back to article You're in charge of change, and now you need to talk about DevOps hater Robin

Here you are, doing the DevOps so hard you've broken the spine of your DevOps Handbook, but Robin won't get with the whole "culture thing". Robin sits in the stand-up meeting, arms crossed, each morning mumbling "Well, I wrote some code" and then takes that long, loud sip of tea. And who's going to have to do something about …

  1. deadlockvictim

    Change for the sake of change

    If it has worked in the past, is working now, there's a good chance it'll keepi working well into the future.

    If it ain't broke, don't fix it.

    Change for the sake of change? How about properly and exhaustively testing it first?

    I feels some empathy for the Robins of this world.

    1. Anonymous Coward
      Anonymous Coward

      Re: Change for the sake of change

      At most places, almost everything that is still delivered manually by humans (including but not limited to system configuration and code change management processes and ITIL and waterfall derived development methodologies) is still broken. So the question is not 'if it ain't broke' but more like 'what must we fix through yet more disruptive changes and what else can be fixed by following a better (usually more automated/iterative) approach but within the existing organisational structure and aligned IT business processes we've already established?". The origins of DevOps came from the frustration of the developers not having control (or visibility) of the underlying production infrastructure and the production system operators not having control (or visibility) of the development software stack. Encouraging the two (previously separated) teams to work together on 'agile infrastructure with continuous, iterative application deployments from bottom up' where the whole stack of system and application dependencies are treated as a whole, along with the delivery of the required changes should tie everyone together, including both hardware and software test teams, who in many large IT service providers were traditionally kept separate as hardware/systems operations teams didn't code much and software development teams didn't care enough about the hardware their applications were running on and if/how it operated. Now that its running 'as a service' on someone else's computer, there may be more concern about the what the system owners might be doing with the physical kit or host OS that the application software is running on.

      1. yoganmahew

        Re: Change for the sake of change

        "The origins of DevOps came from the frustration of the developers not having control (or visibility) of the underlying production infrastructure and the production system operators not having control (or visibility) of the development software stack."

        That may be the origins of devops. The reality of devops now is the agile, PMP, ITIL-certified loving paper pushers have taken over with their forms based processing. They spend their days dreaming up new ways to stop development happening, constantly changing SNOW workflows (a tool that now automates their warblings into actionable damage to the organisation) and living in their unaccountable ivory towers.

        No one is less accountable to the customer than devops, no one. You'll never see devops on a call with a customer explaining why it take three months for a standard change to tick all the boxes, why the fastest an emergency change can be done is a day, unless the CIO explicitly says "skip the process" and then it takes five minutes.

        They are shitters the lot of them.

    2. Andrew Commons

      Re: Change for the sake of change

      Once upon a time....there was this sudden push to go 'Agile'. This was OK but having spent a bit of time in the process improvement space I started asking some questions. These were along the lines of 'what is wrong with the current methodology', where is it failing; 'what do we want to keep from the current methodology', where is it working; and 'how do we measure success'. After a lot of ducking and weaving it came down to 'HR think we will not be able to recruit young people unless we are 'doing Agile'. And DevOps is different because...

  2. Anonymous Coward
    Anonymous Coward

    Correlation, or cause and effect?

    "'companies with highly engaged workers' grew revenues two-and-a-half times as much as those with low engagement levels"

    This comes from a management book, and seems to imply that if you get your workers highly engaged, then your company will grow faster.

    But could it not just be the other way round: a company which is growing rapidly is an exciting place to work?

    Equally, a company which is flatlining tends to be more obsessed with cost cutting, which doesn't really do much for employee motivation.

  3. Anonymous Coward
    Anonymous Coward

    Perhaps Robin has it right.

    Maybe Robin thinks it is a fad. An overpromoted fad, relentlessly advertised in some otherwise reputable sources. Just saying.

  4. Tom 38

    This round of transformation might be the same squiggly pit of offal as the ones that came before. Throughout their career, the Robins have been force-marched through several searches for excellence and are now ready to ensconce themselves in a lovely, little cottage curating their model-train collection.

    Yes, that's right - if you're not onboard with the DevOps mission, you're some miserly old fogey who collects model trains and it would be easier if you just retired or died, because no criticism of the glorious culture can be accepted. Fuck off.

    1. Wensleydale Cheese

      "Throughout their career, the Robins ... are now ready to ensconce themselves in a lovely, little cottage curating their model-train collection."

      The Robins must have been well paid then. Have you seen the price of model trains and lovely little cottages nowadays?

      Stomps off to cut the lawn...

    2. yoganmahew

      "Fuck off"

      If I could upvote this more I would.

  5. This post has been deleted by its author

  6. This post has been deleted by a moderator

  7. Anonymous Coward
    Anonymous Coward

    Je suis Robin

    and I think many commentards here are. Though I don’t do model trains.

    1. handleoclast

      Re: Je suis Robin

      Yep, another Robin here.

      Not the model trains, obviously, but everything else.

      This seems like yet another EPNS bullet. It may be shiny but it's not going to kill any werewolves.

    2. Anonymous Coward
      Anonymous Coward

      Re: Je suis Robin

      You'll have to send me Batman's mobe number

  8. Paul Smith

    Every fad that I have come through has, with hindsight, brought at least some advantages over its predecessor but not one single one of them lived up to the marketing hype, and most even failed at their major selling point. Remember how OO was going to create a world of reuse-ability? When will the evangelists get the message that each fad they are singing the praises of is not "THE ANSWER", it is just a tool, and that every professional knows that some tools are better at some jobs then others.

  9. Jim 59

    Regarding stand up meetings, they are just as boring as the old fashioned sort, but more uncomfortable. And they go on longer, because everybody has to say something.

    1. Roger Kynaston Silver badge

      O/T stand up meetings

      What happens when you get stood up at your stand up meeting?

      It is too warm at the moment but I'll get mine.

    2. Doctor Syntax Silver badge

      "Regarding stand up meetings, they are just as boring as the old fashioned sort, but more uncomfortable."

      With my bad back a stand-up meeting would have been followed by an industrial injury claim.

    3. JohnFen

      Daily standups are BS. If your team is functioning well, then everybody knows what everyone is working on every day without doing a standup. If your team is not functioning well, then you're better off fixing that problem than adding more meetings.

  10. Anonymous Coward
    Anonymous Coward

    The big problem with DevOps is that it has a tendency to be a lot of Dev and very little Ops, because the Dev is interesting and exciting, and the Ops boring and hard work (and more risky and visible).

  11. Velv


    Great if you're changing the snazzy front pages of this months hipster coffee house :)

    Not so good if you're handling transactional data for peoples salary and mortgage payments :(

    1. matjaggard

      Incorrect. And a good example of why little FinTech startups are beating the big boys in some areas.

      1. Andrew Commons

        FinTech startups

        They are not big enough to cause a fuss if they fail and haven't been around long enough for their failures to catch up with them.

      2. yoganmahew

        "Incorrect. And a good example of why little FinTech startups are beating the big boys in some areas."

        Like TSB?

  12. Anonymous Coward
    Anonymous Coward

    DevOps - nearly a decade old already?

    DevOps started almost ten years ago as 'agile infrastructure' which was made possible by the rapid adoption of more reliable hypervisor APIs like ESXi that can run on commodity x86 kit. Once your physical servers, network devices and storage are racked according to an 'off the shelf and get what you are given' standard catalogue, how quickly can you completely rebuild the whole software stack from scratch, using nothing but the base OS install images, application installer binaries and a bunch of shell scripts? If the answer is more than a day, try again. It is perfectly possible to rent a fully configured, basic bare metal server with fast enough network links and storage for a whole month for less than a weeks wages or even just a few hours for a days wages. Replacing commodity infrastructure is an order of magnitude cheaper than most of the (licensed/supported) operating system and other software stacks that many companies still feel tied to on top of whatever physical kit their hosting 'on premise' or in a service providers 'private' data centre. This is especially true when you move to HA solutions that require more complex clustering, those typically start around six figure prices and climb rapidly, whereas some of the commodity kit they can be hosted on is still an order of magnitude cheaper to buy (or rent) than the big brand software support. The idea is that once you can reliably rebuild and recover a 'bomb-proof, production-like' 'full stack' solution from scratch within an hour or two (data permitting!) do you really need to worry as much about managing changes breaking single (or even multiple) parts of that stack? Search for the Velocity 09 presentation given by Allspaw/Hammon from Flickr about 10 deploys per day for a heads up.

    1. Doctor Syntax Silver badge

      Re: DevOps - nearly a decade old already?


      Please Google the newfangled-term "paragraph".

      1. Keven E
        Thumb Up

        Re: DevOps - nearly a decade old already?

        Well done, Doc. I just look at those two and know very well I won't get to the end... and then don't bother trying..

  13. Headley_Grange Silver badge

    Embrace the Change

    Maybe Robin is sceptical because the same people who can't go fast enough in embracing DevOps, agile, etc. aren't interested in dealing with all the other arseache processes which haven't changed since they were first written down in Latin - like expenses processing, getting a hire car authorized, needing 6 directors' signatures to download something onto a USB stick, having a joined up config management system,......., etc. Just ask Robin - he'll have a list.

  14. disgruntled yank Silver badge


    "and have since learned the proper way to ride the stack-ranked wave without drowning."

    (Perhaps they resort to Stack Overflow?)


    "Ultimately, it's best to first be empathetic and humane, even using people like Robin as a canary in the change coalmine."

    (Does this mean that when Robin dies of noxious gases we'll save the others? Or is it the irresistible attraction of bird names? And "change coalmine"--you dig for small coins as well as coal?)

  15. Herring`


    I can't help but get the feeling that the reason people are sceptical about the inevitable introduction of new shiny methods is this: Management is incapable of seeing itself as part of the problem. I've seen it when management declares that things are "agile now", but that's just something for the coders. Management still want specs and (wildly inaccurate) estimates up front. They still want their change control boards once a month. They still want to feel that they're actively managing everything - even if what they're doing is actively opposing the very method that they claim to embrace.

    I don't know if anyone else has experienced this, but back in the day we used to get huge levels of productivity by developers and expert users talking all the time - even sitting together. There was no need for "daily standups" as everyone was working together all the time. Management did sod-all - it was highly profitable so don't interfere.

    1. Anonymous Coward
      Anonymous Coward

      Re: Fads

      Herring - how did you know you were getting huge levels of productivity back in the day if you didn't have specs or budgets?

      1. Herring`

        Re: Fads

        Cos the next release went out on time and thousand of users all round the world loved it

    2. Anonymous Coward
      Anonymous Coward

      Re: Fads

      What he said.

      Worked in a company that insisted they were "embracing Agile", but they still kept their 6-monthly release cycles.

      Any change you wanted had to be requested for the release after the release after next. This is because the next release was already in test(*), and the one being developed after that was already full in terms of feature or change requests.

      So it boiled down to a minimum 1 year wait for any change.

      (*) Testing was still being done manually, of course

  16. Robin


    Why am I getting it in the neck all of a sudden?

  17. Doctor Syntax Silver badge

    I'm sure one of the reasons why businesses prefer young recruits to experienced old hands is that they're easier to impress. After a few "latest things", each insisting that the previous things were wrong, experience brings scepticism.

    Management doesn't like its newest, brightest idea to be greeted with "Oh no, not another one." or "Meh". Even less do they like to be told "That's what we were doing in the '80s, all gussied up with new names. However little they charged you for that you were done.".

  18. JohnFen

    Stop assuming "change resistance"

    It is inaccurate and insulting to assume that people are resisting Agile and Agile-related approaches because they "hate change". Often, the resistance is not because of change resistance, but because they have made an assessment that these approaches aren't in the best interest of the customers, company, and industry. Often that assessment is directly due to a lot of experience with this sort of approach.

    The way to address this is not to make some sort of emotional appeal, but to take their concerns seriously and to address them with actual responses rather than recited time-worn (and almost always misguided) platitudes.

  19. Anonymous Coward
    Anonymous Coward

    I am sure DevOps can work

    If you employ the right experienced and skilled people (but then they'd work well in other models), probably work well for the internal stuff I deal with - trouble is management want it as a way of cutting costs to almost nothing, which means low experience levels and/or low skills.

    Questions that were asked about a new newfangled agile project by management - less issues? not really, it however was done in half the budget for more radical changes over a shorter period, so I'll accept that from what resources we had (who are probably in new roles so all that learning about the business will be gone and not available for next project).

  20. Mr Gullible

    Maybe Robin's just fed up with clueless managers imposing the next silver bullet they've read about in mangler's weekly in order to pad out their CV and thinking that by shouting 'DEVOPS' (or whatever the current fashion is) at every opportunity, everyone (their own managers in particular) will think they know what they're talking about.

    1. Anonymous Coward
      Anonymous Coward

      I used to read all the magazines, electronic or paper, that "A Proper CIO" should read. After a while I noticed the trading in the old shiny for the new shiny without, it seemed, even caring about any downsides of the new shiny. Now, I just login here. Far less effort involved.

  21. Anonymous Coward
    Anonymous Coward

    What is DevOps

    DevOps a recent buzzword invented by PowerPoint Ninjas, Conference Organisers and Consultants to describe a methodology for siphoning money from PHB training budgets.

    More specifically, it is a fusion of:

    * Continuous Delivery (A concept borrowed from Sewage Engineering)

    * Agile (Borrowed from Gibbons)

    * Talking (Borrowed from Homo Erectus)

    * Selling Magic Tools (Borrowed from Elves and Dwarves)

    * Beta Test in Production (Borrowed from early Egyptian Pyramids)

    * Unit Testing (Borrowed from Smalltalk circa 1998) isolation none of these strategies can shift tickets for an undersubscribed conference or bag £1000 a day consultancy fees, but combined with "thought leading" obfuscators educators there is hope they might address pressing business needs to reduce training and tooling budgets (by giving away money) and reduce customer complaints (by making failure the new standard).

    ​(Stolen utterly without permission from Register commentard Lysenko.)

  22. doublelayer Silver badge

    Way to be completely unbiased

    "Robin sits in the stand-up meeting, arms crossed, each morning mumbling "Well, I wrote some code" and then takes that long, loud sip of tea."

    OK. You clearly went to some effort to always mention Robin in a nasty light. That's not going to help you convince those of us who think devops is pointless to like your argument. Maybe next time, you could grant that there are valid questions such that the most positive term for someone who didn't buy in immediately isn't "justifiably crotchety".

    Here's the major problem with devops. We're not sure what it really is. We understand that you think it's a thing, but your articles seem to contain sections that were written by the "big buzzword generator". To me, a lot of them seem to say, under the jargon, that there are problems and we need to make them into not problems. It doesn't say how to do that, other than making some suggestions that we already know about. For example, having meetings and discussions seems to be a major part, with the various sections having contact with each other so that a problem noticed by one can be made known to the others so that one of them will make it into a not problem. That's not new. The reason a lot of software is crap isn't because people were thinking "I never thought that one group should note problems to the responsible group", but because the responsible group didn't care, the problem went to the bottom of a pile of papers, or management pushed the software through.

    In addition, devops seems to be a project that, whatever else it does, will generate a lot of paperwork. I hate to inform you of this, but having systems requiring a lot of incidental work just to keep the system running makes things bog down. For example, the company I used to work for, where we all had to get up and have a meeting that often lasted at least four hours, during which everyone discussed their projects, was counterproductive. I had nothing to do with many of those projects, so while I listened to details that I couldn't use and problems I couldn't help to solve, I was not actually doing my job. That meeting system has, I'm told, been canceled.

    Here's what you have to do to start to satisfy me with this devops system, if you're interested. First, stop using clearly biased language, perhaps to try to sound humorous. It's irritating me, at least. Second, be really clear about what each thing is that you're talking about. If a theory says do small unit tests, don't phrase it in several paragraphs of explaining what incidental systems are required, say "run many small unit tests". Finally, explain not just what the system is, but why it's going to work in practice in the real world. Explain how someone explains the philosophy to a manager who actually listens and wants to understand, and how to use it to avoid the problems that actually exist.

  23. matjaggard

    Wow, the commentards are out in force on this article kicking the DevOps culture that's so successful but sadly doesn't fit with their 1980s IT industry.

  24. Fokko ukena

    I promoted myself to devops manager when I managed to get developer colleagues to stop changing file permissions to 777.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022