back to article Ready for DevOps? Time to brush up on The Office and practise 'culture'

DevOps is the Holy Grail that could save your IT architecture – or so we’re being told. Do DevOps properly, and the IT department can deliver software continuously and fix complaints more quickly. This makes line of business managers happier, which is lovely. It also gives you more time to listen to their requests for new …

  1. Little Mouse Silver badge

    Am I missing something?

    DevOps - A real "thing" or just more management wankery?

    It reads like nothing more than a wish-list of all the "mission statements" and "core principles" that middle management aspire to, all chucked into a bucket, stirred a bit, then rebottled with a nrw name as if it's some Holy Elixir.

    1. Anonymous Coward
      Anonymous Coward

      Re: Am I missing something?

      I came to ask the same thing but wouldn't have put it quite as well as you. The company I work for is still going on about COE (Centre of Excellence)

    2. Moonunit

      Re: Am I missing something?

      Polish a turd and you end up with a shiny* turd.

      I think boatloads of us elder duffers have seen all sorts of nonsense come and go over the years. Same crap, different wrappers.

      *Actually, you end up with an utter mess, but Management Wonks would have you believe in the shiny outcome.

      1. Moonunit

        Re: Am I missing something?

        Bugger me ... just noticed I'm 5 days late to this party! Seems NY's eve was better than expected!

        If the company culture is up to maggots, and if management is clueless, well, you can toss any label/system/methodology/whatever about and still be guaranteed to spend n times as much for 1/n of the desired result ... and a solution which isn't.

        /returning to my vat of CH2O now/

        (subscripting lost, "2" not subscripted as it ought to be!)

        1. Anonymous Coward
          Anonymous Coward

          Re: Am I missing something?

          Here you go. CH2O

  2. Roger Greenwood


    Would be a good place to start if you don't already use it and the latest version (2015) is now much more IT friendly.

    1. Destroy All Monsters Silver badge
      Paris Hilton

      Re: ISO9000/9001

      Good for hotel room management,

      IT operations (and even development?) Not so much.

      Even if quality gurus affirm otherwise (they wouldn't be gurus if they actually spent the time doing the stuff they are talking about though, they would just be another trash compactor maintenance person)

      1. Doctor Syntax Silver badge

        Re: ISO9000/9001

        "Even if quality gurus affirm otherwise (they wouldn't be gurus if they actually spent the time doing the stuff they are talking about though...)"

        Quality is like sex. Those who are always talking about it probably aren't doing it.

    2. Crazy Operations Guy

      Re: ISO9000/9001

      The only way that that ISO bullshit has helped my company is through our audit wing charging customers metric tons of cash for the audit and ISO certification.

  3. John 104


    Another week, another DevOps article.

    And yet, no one can seem to make it work.

    Like Little Mouse said, its just more management mumbo jumbo. And the fact that there is now a coined term to highlight "How to do it!" should tell you something...

    I've espoused my experience and distaste for the idea here many times. The only way it could possibly ever work is if you had a CTO who was proficient in both development and infrastructure and was able to view things objectively. Such people are rare to say the least.

    1. Doctor Syntax Silver badge

      Re: Sigh

      "Another week, another DevOps article."


      or maybe


  4. Anonymous Coward
    Anonymous Coward

    Sometimes it can work, sometimes it can't...

    One size never fits all. In some environments (and applications), pushing changes continuously can work. In other, it can just create havoc - and it's not because of "culture" - it's because of the needs and complexity of the environment itself, and no technology will help.

    1. annodomini2

      Re: Sometimes it can work, sometimes it can't...

      Ah but the management consultants wouldn't have anything to rip off customer with.

  5. <shakes head>

    and legislative speration of duties

    he who builds shall not run, he who runs, shall not fix.

    1. P. Lee

      Re: and legislative speration of duties

      >he who builds shall not run, he who runs, shall not fix.

      For we shall silo our expertise into different outsourcerers on the grounds of cost-cutting, in honour of the mighty god Mordac, Preventer of Information Services. Our fixers shall fix in the Philippines, our runners shall run in India and our builders shall build locally. For lo, MultiNational Enterprises are a Success by Definition, are they not? And the explicit cost savings shall be half my bonus for achieving them, while the hidden costs shall be identified and moved around by a new incarnation of Mordac, who shall appear after the opening of my parachute of gold.

      We have taken the holy words of Scientific Management and repackaged them, for we know that McDonalds and Foxconn practises are great in the eyes of Industry.

  6. Crazy Operations Guy

    American or UK?

    So which version of The Office? Much like The IT Crowd and Doctor Who, the UK version is a damn good show, whereas the American version makes me want to invent a time machine and assassinate Philo Farnsworth as a child so that television is never invented.

    1. Anonymous Coward
      Anonymous Coward

      Re: American or UK?

      Much like The IT Crowd and Doctor Who, the UK version is a damn good show

      I must have missed that U.S. version of "Doctor Who"

  7. bailey86

    Devops is vital to produce good systems/websites/applications and to maintain them.

    One developer working on a new site/application which is not live yet - easy.

    One developer working on a site/application which is now live with transactions/articles etc flooding in - not so easy.

    (Remember folks - the days of static websites are pretty much behind us).

    Many developers working on a live site/application simultaneously - very hard. Devops needed.

    Get it right and the stakeholders can be extremely happy - a team (which, ahem, I set up the Devops for) received (expensive) champagne for a project delivered ahead of schedule.

    Most of the time there are two main problems.

    The first is developers who have no idea about Devops and have no inclination to work as part of a team. If you have developers like this then the only way Devops can be implemented is with CTO backing.

    This brings us to the second problem. Most management do not understand the need for Devops. They think that their genius developers can all work together on the same systems without any management/devops - as if by magic. Then they are puzzled why nothing gets fixed anything like quickly.

    The good news - the kidz who know their stuff are trying to sort it out. Github/Bitbucket, Pull requests, CI tools like Shippable/CircleCI, automated testing, Heroku, hosted MySQL/CDN's, Javascript apps sitting on REST API's, Slack, Basecamp, Ticket systems, etc, etc. But unless there is CTO buy-in to get someone to implement this properly then most projects will turn to mush after they go live.

    And this is a key point - before a project goes live it's easy - any part can safely be bodged around with - progress seems to be good. As soon as it's live the development grinds to a near halt.

    One of the answers is that the whole development and deployment to live needs to be sorted out at the very beginning of the project - before any meaningful development has taken place. So,as an extreme example - a live site could be initially set up with a single 'Hello World' HTML page (behind HTTP AUTH etc) and the developers are set up to deploy their changes safely to live during the development process. Site editors can also be adding content to the new 'live' site. Then, 'going live' means simply removing the HTTP AUTH - and - crucially - further development is carried out in exactly the same way that development was carried out during the site build.

    The final part of this is missing from most places where I've worked - and it is key - difficult - but key. Automated testing - primarily BDD testing I would say over unit testing. Imagine your site/application having every single aspect built with a test implemented at the same time. I've worked somewhere where websites could have a few thousand tests each. So a developer makes a change - large or small - and after they submit their change three thousand tests run (on dev/QA/staging etc) to check everything else on the site/application still works. Beautiful - and the way it should be done.

    And I agree with the article - this Devops needs to be maintained/enhanced throughout the project development cycle - and even into the maintenance cycle.

    1. John 104

      Re: Devops is vital to produce good systems/websites/applications and to maintain them.


      Congratulations. What you have described is what I call Dev Dev. Not once in your comment did you mention systems. For Dev-Ops (emphasis on Ops) to work, both parties need to be involved. That's the goal, right? Rapid, collaborative development and deployment of applications to production, involving all required teams to meet customer needs.

      If your development team uses the Agile method or scrum or whatever, welcome to 2010+. That isn't Dev-Ops. It's just you doing your job. :) Sorry if it comes off snarky, but this is the problem with "Dev-Ops". Developers are all over it, but have no idea what it really is supposed to mean. Then they deliver a product to engineering and wonder why it won't get released to production or why there isn't capacity for it. Dev Dev.

      1. bailey86

        Re: Devops is vital to produce good systems/websites/applications and to maintain them.

        'Congratulations. What you have described is what I call Dev Dev. Not once in your comment did you mention systems.'

        Of course (live) systems are involved in what I wrote. That's why I put the example of the live hosting being implemented from the very beginning of a project. And that would obviously include how those live systems are maintained etc. It was a main point of what I wrote.

        As an extreme example, too often this is only thought of after a developer has built a site on their laptop. Some live hosting is arranged, the site is now copied to that hosting - and only now does anyone think of how to deploy changes to the live site in a managed, tested and safe way.

        I thought I'd made it clear. And automated testing should mean that deployment to live is trivial. In fact, I worked in one place where devops was done well and deployment to live was carried out by junior devs.

        And also, it is why you need CTO backing. To implement Devops you need be able to organise both development and systems - and CTO backing will be needed because very often those two groups will dig their heels in.

  8. Mark 85

    If you have managers in place who rule through fear, humiliation and threats, it might be time to rethink your team before you start.

    Like many other things that seemed to be a good thing in their time, this ^^^ will guarantee failure. I don't know of any company that doesn't have management in place like that. Maybe not at every level and every department but enough are around that they will sabotage anything that involves changes in thinking and action.

  9. Anonymous Coward
    Anonymous Coward

    I've only been exposed to the "DevOps" movement for about a year as the company I work for is looking into doing it, but I've been reading up, listening to podcasts, webinars etc and from what I see is that the origins are in Lean, which in itself comes from the Toyota Production System. If you drill down the the base philosophy of continuous improvement, eliminating waste (wasted time, resources etc) and ignore all the hype, tools and BS, then I think DevOps can work.

    I'm reminded of a story in one of the books I read about TPS, where the auto industry said it won't work. They would go to Toyota, record and copy everything they did and replicate it. It didn't work. They would go back and find that Toyota did everything different again, because they way they work continuously evolves. I think that is the point, continuous evolving to try to get better. I think the failures to implement come when you ignore the "evolve" part and just expect it work aka a silver bullet eg. you have CI/CD in place, automated testing etc, you're doing DevOps. That is what I'm seeing in the company I work for at the moment.

    Anyway, that is my opinion given I have no practical experience, only what I can work on in my own time. So take with the appropriate grain of salt.

    1. Mark 85

      Isn't this just another form of what Deming wrote about and put into practice? The US bought it and ran with it in WWII and then dropped it. The Japanese embraced it and apparently still are.

      1. beanie2012

        Yep, that's how I see it.

  10. Mellipop

    All your tin are belong to us

    Any company that builds and runs and maintains a web site with no help from design agency and minimal resources from the hosting service, have been doing devops.

    Any company that has built an application in Google App Engine or Amazon Web Services has been doing devops.

    Devops ; development, and operations. Normally two silos in many companies that run their own Tin. In my company it is three because we also have Application Management. Or is it four because of our global help desk service?

    But you get the point. Small companies that wanted to use WWW and Cloud have been doing devops because it was the only way they afford to get into it.

    Devops according to this acronym (CAMS) is about trying to scale the essential feedback loops to big systems, currently tended by hundreds of people managed by possibly more people across multiple departments using mostly broken administration services from the last century.

  11. John Smith 19 Gold badge

    "Must get managemetn buy in."

    What usually kills these sorts of cunning plans.

  12. STZ

    DevOps is a very rare type of person ...

    ... living within a small company. As an IT superhero, that kind of person will actually be able to create a service, run that service properly and keep adapting/improving it at the same time.

    Don't expect to find many superheros of that kind, don't expect them not to realize how precious they are, and don't expect to have them very long - you will lose them either to higher paying companies or due to burnout.

    And don't expect that DevOps could be a suitable working model for large organizations.

  13. Anonymous Coward
    Anonymous Coward

    Acronyms or not....

    "John Willis and Damon Edwards, who co-host the long-running DevOps Café podcast, have coined the term CAMS that stands for: Culture, Automation, Measurement and Sharing."

    Here, I'll coin another term CRAP that stands for....

  14. usmsystems4

    DevOps Potential

    DevOps potential has received a great deal of attention because of its advantages. Software change requests are quite common and are most expected during the software development phase. Project managers need to consider change requests for a successful project delivery because responsiveness to change requests is key to customer satisfaction and an important ingredient of project success

  15. DJSpuddyLizard


    Sounds like Business As Usual in small IT shops

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

Other stories you might like