back to article Happy mode, sad mode, DevOps mode: Stop worrying and go bimodal

There’s a debate going on right now about the best way to run IT: specifically, all those custom applications and services inside organizations. Do we try new, agile approaches, or stick to the old, methodical processes? Gartner did much to start this discussion with their bi-modal concept: Bimodal IT is the practice of …

  1. allthecoolshortnamesweretaken

    "Do we try new, agile approaches, or stick to the old, methodical processes?"

    May I take this to mean that there is no methodology behind agile at all?

    1. Anonymous Coward
      Anonymous Coward

      Re: May I take this to mean that there is no methodology behind agile at all?

      THERE IS NO METHODOLOGY BUT DEVOPS

      DEVOPS IS THE MOST IMPORTANT THING EVER AND WE JUST WON'T SHUT UP ABOUT IT

      YOU ARE GETTING VERY SLEEPY

      1. allthecoolshortnamesweretaken

        Re: Re: May I take this to mean that there is no methodology behind agile at all?

        Friends don't let friends do DevOps.

    2. Dan 55 Silver badge

      I starting to think these El Reg agile articles are actually a guerilla campaign to bring agile into disrepute.

      "Do you want your boring, old, planned development environment or would you like to spread fishpaste on every keyboard, set a bunch of cats loose in your office, and commit the result of that at 5pm because it's disruptive? Hell yeah!"

      1. Anonymous Coward
        Anonymous Coward

        ..a guerrilla campaign to bring agile into disrepute.

        Well, all these articles are making me think that DevOps is the most annoying thing ever. Even the FishPasteCatsOps you've suggested looks more attractive.

        Time for a new El Reg slogan? "Biting the hand that feeds IT. Until IT is DevOps, then we'll lick their fingers."

  2. pdh

    Continuum

    Maybe instead of bi- or tri- or quad-modal it makes more sense to think about a continuum. At one end, when a project or idea is new, speed and ease of experimentation are paramount. So move fast and sure, go ahead and break things from time to time when you're at that stage. But if the project succeeds, people start depending on it, and stability becomes more important. If you're doing it right, there's a natural progression rather than a fixed dichotomy.

    This is true even for new, disruptive businesses. In the early days of, say, Uber or Twitter or Facebook, an occasional burst of unexpected downtime was probably quite acceptable if that was the cost of rolling out new functionality at a rapid pace. But now that those companies are successful and established, they're probably much less willing to risk unplanned downtime -- service disruptions now trigger immediate snarkery from world + dog + vulture. Or think about AWS -- an occasional glitch in some new experimental / beta service is to be expected, but we expect EC2 and S3 to remain stable and reliable all the time.

    So you evolve -- you use agile when it's appropriate, and you use stricter change control when that's appropriate. Different processes and standards for different stages of the project's lifecycle -- a continuum as the risks and costs and opportunities change over time.

    1. BoldMan

      Re: Continuum

      Fuck me sideways. someone talking sense for a change rather than whalesong and joss-stick bollocks!

      1. Mellipop

        Re: Continuum

        You wish.

        All that happens is the slow speed governance is wrapped around any agile solution delivery.

  3. Mr Flibble
    Trollface

    Peace? I don't think so.

    What is it with these hippies and sticking two fingers up at people behind them…

  4. allthecoolshortnamesweretaken

    Aw, what the heck - you know you want it: Pizzicato Five - Happy Sad

  5. Anonymous Coward
    Anonymous Coward

    Bimodal IT is a consequence, not a proposal

    I agree that the happy/sad mode is not ideal and that it would be great to run everything in awesome mode, but then again, remember the push for "application modernization" some years ago? I don't have numbers to back this opinion, but I don't think it was very successful.

    To me, bimodal IT is a consequence rather than a proposal. It is:

    - Gartner saying "ok, we know that no matter how much we press you into modernizing your legacy apps you won't do it, so ... for new projects why don't you try this modern approach"?

    - Accepting the fact that there are new kinds of IT buyers (ie CMOs) that need new kinds of projects ("why don't we build a gif creator platform to support the new advertising campaign?") that need to be built in a couple of weeks and will only be live for a couple of months.

    - Recognition that it is too much to ask of CIOs to support business as usual at max stability+efficiency while at the same time developing new digital products/services. That is why we are seeing the rise of the corporate CTO. The CIO is responsible for business as usual (ERP, payroll, reporting, etc) and the CTO leads exploration/development of digital products/services. Both are important. One allows you to operate today, and the other allows you to be in business tomorrow.

  6. Anonymous Coward
    Anonymous Coward

    This really happened

    I was working on a large-scale very high profile product for five years. Development was a mess, project management was non-existent, egos were rampant, nothing worked, teams weren't cooperating, the UI was terrible and we were being continually and publicly mocked for being impotent and talentless failures. Morale was rock-bottom, the project was in a death spiral, and none of us from junior to senior could see a way out. People left in droves.

    Then we adopted DevOps, and in three weeks we'd turned everything around and got our new product - Windows 10 - pushed out and installed on millions of PCs. Now if that's not a DevOps success, I don't know what is.

  7. Pascal Monett Silver badge
    Mushroom

    "Do we try new, agile approaches, or stick to the old, methodical processes?"

    JUST SOLVE THE FUCKING PROBLEM ALREADY.

    I swear to God all this intellectual masturbation about development procedures is seriously getting on my nerves.

    No later than this very afternoon I had a conversation with one of my customers. A shop with 2000+ employees and an IT sysadmin very much on top of his game. He told me that one of the procedures that we put in place to ensure proper transfer of data to the mainframe (yup, that still exists out there IRL) had been reported as not working.

    Well guess what ? The mail-in where the info was supposed to be sent wasn't being used because some jackass middle-management wanted the info on the side to do whatever Godawful Access thingy and get some vested-interest statistics out of the data. The fact that Business Intelligence Central no longer had the data was a case of Not My Problem (for said manager, of course).

    As a seasoned veteran with complete access to all data streams, what did he do to solve the problem ? Simple, really : he instructed the database receiving the data to send a copy to the one that should have been used. Bam! Problem solved. Data re-inserted back into the proper stream. Code change : minimal. Time used : 5 minutes. Procedure : who the fuck cares ?

    People who spend their time spouting nonsense about procedures should be relegated to where they belong : university or retirement homes. Real Life is about solving problems, not deciding who should be named whatever the new name for Scrum Master is.

    Now get off my lawn !

    1. Anonymous Coward
      Anonymous Coward

      Re: I swear to God all this intellectual masturbation...

      Have an upvote.

      When I was a young programmer I developed a simple tool to organize some files in floppy disks. The requirement procuration integrator A coworker had some dozen of files for an application that needed to be divided into floppy disks by category/extensions, I have no idea why.

      Our hyperdedicated team of analysts, engineers and developers I wroted something simple in Turbo Pascal (yes!) that copied the files in the desired order. The technology integration evaluator user was quite happy with that.

      Later that year the head of our department decided that we need a Systems Analyst/Software Engineer to "guide us" on the development, and he decided that the first logical step was to evaluate what we did in the past to tell us what we did wrong. In a first meeting he asked me to show every piece of paper produced in the meetings with the stakeholders for that small piece of software. I had to "respectfully" explain that the users' problem was solved, and I wouldn't work to justify hiring that douchebag moron specialist with pointless paperwork.

      After one year, one of us was fired. Surprisingly, it wasn't me.

  8. AbstPoolAuto

    I like the analogy to the wild west

    There is a guy called Simon Wardley that talks about pioneers, settlers and town planners when describing this phenomenon and it helps me because it puts it in human terms that my fragile cortex can deal with.

    When the west of the US was first colonized by immigrants it was typically the pioneers - the adventurers that wanted to break new ground and discover untold riches. Another group followed them, the settlers. Life wasn't easy for the settlers but they were effectively able to take advantage of the pioneers effort to discover new produce and then sell it back to the east. The settlers had sheriffs, and hostels, banks and bars but it was still a pretty tough and violent existence. Ultimately the town planners followed the settlers and began to develop the towns and cities that both took advantage of the new resources at industrialised scale and developed all the support structures that a growing population needed - schools, hospitals sewers and the like.

    It is a pretty easy comparison to say Pioneers= innovators, settlers=early adopters and town planners = ITSM and ITIL folk. As PDH says above its a continuum - the trickle needs less management than the flood that follows.

    1. Pascal Monett Silver badge

      Re: it was still a pretty tough and violent existence

      It was certainly a tough existence. It was, however, far less violent than we generally think.

  9. Potemkine Silver badge

    in other words

    "Avoid dogmatism, favor pragmatism" - it doesn't sound stupid to me.

  10. Wings2i

    BiModal IT

    Quite an informative read on the Bi_modal IT concept...

    Wings2i

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–2019