Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Programming IT Technology

Signs You're Doing Devops Wrong (infoworld.com) 166

snydeq writes: Misconceptions and flawed implementations may have many organizations missing the true upsides of devops, writes Adam Bertram in his article on devops practices gone wrong. "Saying that your company embraces devops and regularly practices devops techniques is popular nowadays, and it can serve as great PR for bringing in great talent to your team. But in truth, many companies — and technical recruiters — that are proclaiming their devotion to devops from the hilltops aren't really devops organizations."
This discussion has been archived. No new comments can be posted.

Signs You're Doing Devops Wrong

Comments Filter:
  • Sign #8 (Score:5, Insightful)

    by offa ( 4343345 ) on Wednesday December 09, 2015 @01:19AM (#51086527)
    Expecting "Devops" to be a panacea and the answer to every issue you face.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      s/devops/scrum/g

    • by Taco Cowboy ( 5327 ) on Wednesday December 09, 2015 @01:50AM (#51086643) Journal

      I am a developer, I have been a developer for a number of decades, and I run businesses which deal in the tech scene in many location worldwide

      I can tell you one thing about these 'devop', 'scrum', 'agile' or whatever the new fuck-of-the-day trend they manage to come up ... PROGRAMMING IS PROGRAMMING and everything else is just addons

      I have let some of my branches experiments with some of these bullshit schemes, just for experiment sake - and the result, at least to me, have yet to be impressive

      Back when I started we have none of these, and yet we managed to squeeze in almost unimaginable functional stuffs within really ridiculous tiny confines (4K of RAM, 2K or ROM, for example) and today when we have almost unlimited memory space, all these bullshits that have been advertised as 'cure all' has yet to deliver

      Perhaps I'm an old timer, perhaps the new hipster culture demand to have all these bullshits before they could even start doing anything, I dunno, but my feeling is, with or without these bullshit the most important factor is the PEOPLE

      If you have the right folks with the right mindset, you will get great result

      If what you ahve are lousy people with 'duh!' mindeset, no matter which of the new-fangled bullshit you adopt it ain't gonna give you any miracle

      • by mfearby ( 1653 ) on Wednesday December 09, 2015 @02:49AM (#51086821) Homepage

        I agree. There are so many methodologies out there. I discovered a new one the other day: "kanban". If I were to sum it up myself it would amount to not throwing the baby out with the bathwater and keeping what's good when you go to redevelop a system (at least, that's the impression I got; I'm not wasting valuable hours really delving into yet another methodology).

        I had a boss once whom a former colleague told me once had instructed him to "stop planning and start doing". This was because he had put in a week or two writing a Word document explaining the system and not actually writing it. We're not talking about a massive system either, just an in-house web page in ASP to handle something simple. At the time, we laughed and thought the boss was a loon, but almost 20 years later I've come to agree with him. You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.

        I guess the methodology fanbois would say "agile" is the way to go, and something like it would probably be right. I'm guess I'm an agile developer these days but I don't know a thing about what the methodology actually says. I just get stuck in and "do", and occasionally, if a system is big enough and I'm wary of the users changing their minds all the time, I'll commit the important bits to paper and get them to sign off. Other times, when I know exactly what's needed and we're all on the same page, and the clients don't have that look in their eyes that says they'll be changing their minds a lot, I'll just get stuck in and write the thing without a full-on design beforehand. I find that most designs/plans/whatever are useless by the time the project's over anyway.

        The best methodology is a good separation of concerns with plenty of comments. The rest is just all flash and no meaning.

        • Re: (Score:3, Insightful)

          by Anonymous Coward

          You can go too far in the other direction. Amount of design and planning has to be proportional to the size of the project. Sometimes, yeah, you can just jump in and write the damn thing, but other times you really do need to sit down and think things out at a certain level or you'll get half way though and realize your foundation won't support some major piece of the project.. and then the hacks start.

          Also I'm a huge fan of prototypes as part of the design phase. Easiest way to identify design hickups in t

        • by eulernet ( 1132389 ) on Wednesday December 09, 2015 @08:49AM (#51087579)

          What is the correct balance between "planning" and "doing" ?

          "Doing" works for people with plenty of experience, but they are rare.
          "Planning" works when the project is very complex, but it is rare
          The correct cursor is something between "a little planning, a little doing, and we see what we reached", which is basically agile's definition.

          I'd like to share my experience: I wanted to become an agile coach (yes, shame on me !).
          This was because I saw the opportunity to help people become better, but that's not really what agile became nowadays.

          And I realized that Agile is not for developers, but for managers.
          In other words, it's not designed to help developers, but to make money out of managers.
          You have to agree that the vast majority of managers are completely clueless, so they doubt about their own skills.
          Agile, or most exactly Scrum and Devops, are designed to tell them: you don't understand software development ? No problem, you'll only have to follow a basic algorithm and we promise you that all your problems will disappear.
          I agree that this is quite dishonest, but hey, the goal is to squeeze money out of companies, and managers can use their budget for this !

          What is funny is that most agile gurus are not decent developers.
          They'll explain that such agile game will help people realize something, but they are quite clueless regarding programming.

          • by Anrego ( 830717 ) *

            I think it's a little less "wool over their eyes"-y and more about creating a process where the high level stuff managers care about is easier to track and control and giving developers space to do their thing without managers meddling too much. It creates a clear(ish) demarcation point. Managers worry about things at the sprint and maybe story level, developers make it actually happen. Once it's decided that it's happening, developers (in theory) are left alone to actually do it.

            Contrast that to "pre-agile

            • What agile does for the developer is codifies "I have 2 weeks to code this specific thing, go away and let me do it".

              I wanted to agree with you, but you are clearly too much obsessed by Scrum !
              Frankly, this "2 weeks-sprint" is probably one of the least agile techniques.

              It's like saying: we are in the Titanic, we need 10 miles to turn right. Hey, there is an iceberg in front. No, we need 10 miles, so we'll take 10 miles !

              Agile is here to force managers focus on their work, and let the developers focus on their work.
              Forget daily scrums, forget sprints, just do it in the agile way: as it comes.
              How can I balance between plann

              • by Anrego ( 830717 ) *

                Well, in scrum specifically that's what all the rebalancing is about. You ask "does this amount of work make sense for the window we've got (2 weeks)" and if the answer is no, you add/subtract stuff as required.

                I'm not saying it solves all the problems or has to be rigidly adopted to see any benefit, but I feel like it legitimately does address a lot of very common problems in software dev teams in a reasonably effective way.

                Chunking stuff up into managable pieces has always been good practice for schedule

                • I maintain that this 2 weeks is completely arbitrary, and leads to unregular velocity during the session.
                  You'll get most work at the beginning, and the effort disappears at the end of the session.

                  The worst thing is that some of the nice features get cut in so many parts that we can only implement the least costly ones.
                  This leaves the whole features unfinished and creates a lack of satisfaction.
                  Perhaps it works well for new teams, but for experienced teams, this is a serious problem.

                  Also, an experienced mana

            • Contrast that to "pre-agile" style where managers would just poke in and out and ask about whatever random bit of functionality they happened to care about at the moment or re-prioritize stuff because someone send them an email

              Um, no. pre-agile we had the Capability Maturity Model, Rational Unified Process (RUP), Adaptive Software Development (ASD), Extreme Programming (XP), and many others [wikipedia.org]. And to do any of these "properly" required spending serious amounts of money on training, consulting, auditing, and oooo... don't forget "certification". Entire mini-industries are spawned to handle each of these, for each new "process". Each of them spawn "experts" or "gurus". Some are even able to make doctoral theses out of it.

              Sound fam

          • by rwa2 ( 4391 ) *

            And I realized that Agile is not for developers, but for managers.
            In other words, it's not designed to help developers, but to make money out of managers.

            Oh, perhaps that's the version of "agile" that your managers pushed on you. Agile as specified by the original gang of four had lots of protections for developers. I can understand why most managers end up throwing all that stuff out.

            * Developers are the only ones allowed to estimate the size and dependencies for each task.
            * The business side is only represented by the Product Owner, and they're really only allowed to interact with developers during sprint planning and a bit during sprint retrospective.

            • by gfxguy ( 98788 )

              I agree... I think scrum works if everyone - especially the manager, is on board. Unfortunately, the reality of the last manager I had was that he pushed us all into scrum after some conference or something... and then would get mad at us for not doing the little side-tasks (favors to other people in the company, mainly) at will because we were in the middle of a sprint.

              So, I like it - in theory. It's very hard to get everyone on the same page in practice, though.

          • by gfxguy ( 98788 )

            I agree, but as a programmer there's basic aspects that Agile, in theory, is really good at. Using the entire team to break down the project into bite-size chunks and prioritizing them (although, everybody should be doing that anyway), and I also like keeping the client involved because just about every project I've worked on ended up with the client saying "that's not what I wanted," even if they finally admit "OK, that's what I asked for, but it's not what I wanted." Catching things early on helps. I a

        • You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.

          Absolutely.

          And quite a few companies these days make people spend a boatload of time reporting on what they're doing rather than actually doing it.

          It seems the big thing for the last ten years or so is have everyone do spend work hours doing Weekly Update Reports, Daily Metrics Summaries, Monthly Milestone Wrap Ups, etc etc etc.

          And then they wonder "where did the time go" and "why stuff isn't getting done".

        • I over plan because every time I've had someone not writing code tell me the scope of the thing I'm writing and I ask "will it have to do xyz?" it will eventually end up having to do xyz no matter how flatly it is denied. Last week the turnaround on one of my silly questions ("is the service always run under that exact user?") was less than a day.

          I had already implemented and documented the new variable and which properties file it went in by the time I was told I'd need it. Ditto for things that will
        • by gweihir ( 88907 )

          Unfortunately, how much planning you need to be able to "do" well afterwards depends on the person. I routinely see systems that are completely screwed up because of the lack of planning. They are slow, impossible to maintain, insecure and often do not even fulfill the design requirements. At the same time, they are impossible to replace because there is no specification. Having such systems is worse than having nothing.

          Personally, I find that depending on project, I need between 10% and 50% of overall time

        • There are so many methodologies out there. I discovered a new one the other day: "kanban".

          Sounds like Toyota's manufacturing jargon is making its way into the programming world. Toyota jargon has been popular in manufacturing since The Toyota Way [wikipedia.org] came out. Ever since then, a bunch of Japanese rooted words started flying around manufacturing plants. If they are implemented correctly, many of those techniques are useful and intuitive. However, managers usually don't implement it correctly.

        • by sjames ( 1099 )

          It's an old story. Good developers on a good team will mix approaches as necessary to get the job done. Managers want to turn it into a procedure that monkeys can use to accomplish the same thing but for pennies on the dollar. It's been 50 years but they still haven't learned two important facts. Pay peanuts, get monkeys and monkeys fling poop.

      • Re: (Score:3, Insightful)

        by arkhan_jg ( 618674 )

        It depends what is meant by devops.

        If it means the sysadmins and developers talk to each other and work together in a healthy relationship to deliver stable, scalable apps with heavy use of automation to cut down scut work and human error from both sides - that meet the goals of the organisation - then you're doing it right.

        If it's just a synonym for badly run agile, with devs slapping together whatever to meet arbitrary goals rushed into production with insufficient testing, while sysadmins end up firefigh

        • badly run agile,

          You repeat yourself ;-)

        • by lgw ( 121541 )

          As far as I can tell, "devops" means "fire all that sysadmin baggage, and just pile that work on developers with no ops experience - it will be fine".

          • by johnnyb ( 4816 )

            Or it means "my sysadmins got bored and learned Python" or "sysadmins doesn't sound as cool as devops".

          • by tnk1 ( 899206 )

            It's a sysadmin who can code to a certain extent. Most of the sysadmins that I know are now DevOps Engineers.

            DevOps is not supposed to be a job title, it was supposed to be a philosophy for Development and Operations interacting. Which meant that you'd still have Developers and still have System Administrators, they'd just integrate more closely.

            Needless to say, it now functionally means a sysadmin who can do light coding (useful for software defined cloud stuff like AWS) and understands certain tools lik

            • by lgw ( 121541 )

              The company I work at now just makes the developer do the ops stuff too. No, we don't bring any sysadmin experience to the job, but we're quite good at automating that ignorance. It works exactly as well as you might expect. I'm amazed at how often some team's "lessons learned" after some disaster are stuff that any mid-career sysadmin would do religiously without really needing to think about it. I'm not clear what advantage this was ever supposed to bring, but it wouldn't surprise me if we found out w

              • by tnk1 ( 899206 )

                Having worked at a place kind of like that, I can tell you that ultimately, they considered the functions of the sysadmins and particularly security, to be "in their way", or they simply didn't understand it.

                There were some smart guys who worked there, but they thought that they could automate away the job of Operations. I was impressed by some of the things they achieved with automation, but ultimately they didn't understand operating an application or security. It was probably for the best that their ap

        • by Etcetera ( 14711 )

          Sysadmins need to be part coder these days to do their job properly with automation and flexibility; devs need to be part sysadmin so they can factor performance and stability within sane budgets into their designs.

          The thing is, a (good) Sysadmin has *always* needed to be part coder. If you weren't comfortable shell scripting, you weren't being a good Sysadmin. And once you're shell scripting, and maybe doing some perl or python, it's really just a matter of syntax and project scope to go from there.

          In short, it's easy to take someone with solid Sysadmin skills and experience and teach them more coding. It's a lot harder to take someone with lots of programming skills and teach them systems administration skills that

      • I am a developer, I have been a developer for a number of decades, ...

        Me too - and I agree. Well, mostly. I think these fads are really just about management trying (and failing) to catch up with what developers are. Agile is really just about trying to formalise what a sensible development team already does: talk to each other, make changes to designs when needed etc. The reason it fails is probably that in formalising the process, they try to introduce yet another one-size-fits-all concept, and developers are just not like that. A sales team perhaps, would like it - sales p

        • by Z00L00K ( 682162 )

          It doesn't really matter what you call an agile development style or if it's even documented or not (OK, it's good if there's a trail in some way so you can see what has been done or not).

          What is really scary is those that tries to impose the waterfall style of development - it's something that only works if you design simple hardware items with few ways it can go wrong. On software it can cause a project to go on for years (Half-Life 3 anyone).

          • by tnk1 ( 899206 )

            Half-Life 3, as far as I can tell, is languishing at Valve because no one wants to work on it. My understanding is that the general policy is that Valve employees work on projects that interest them, and a team has not formed that is interested in doing HL3. I do not believe it has much to do with their coding process.

            While there may be some collateral they have produced for it, I don't actually believe Valve has ever actually started working on HL3, so it isn't a matter of them being behind schedule.

            Oddl

      • by Anrego ( 830717 ) *

        Agree it's about people and shitty programmers are gonna be shitty regardless of process.

        That said, as someone who's seen adoption of agile make a huge (mostly positive) difference, I do think changing methodologies can sometimes be a good idea... if for no other reason than it gets people into a "doing something different" mindset rather than a "business as usual" mindset.

        I'll also say that software as a business has changed dramatically. It was never just about programming, but I certainly feel that the c

        • by BVis ( 267028 )

          I agree that shit programmers are going to be shit programmers no matter what, but another problem is shit managers that use the methodologies of agile/scrum/kanban/whatever to further isolate themselves from accountability by blaming everything on the developers. If you're an MBA who can barely run a toaster, yet you're in charge of directing a software project of significant complexity, the shit rolls downhill until your once-good developers are now burned out husks who are indistinguishable from shit pr

      • Yep programming is programming. Agile and Scrum are about project management, DevOps is simply applying similar techniques to the maintenance and infrastructure management phases of ALM. Yes Taco like you I started out with the system specification written on the back of a packet of cigaretts. Just imagine a bunch of management consultants have taken the whole "Writing the spec on the back of a packet of cigs" and wrapped it up in a load of techno bable so that now instead of a packet of cigs you are pre
      • Bingo, and very well said.

        Add to everything you just said that programming, by and large, is a solitary sport, and a lot of this "management fad of the week" shit comes into sharp focus as nothing more than new and innovative ways to waste everyone's time by talking about what they're doing rather than actually doing it.

      • You subscribe to this methodology: http://programming-motherfucke... [programmin...fucker.com]

      • by lorinc ( 2470890 )

        You're old. Back then only few people did programming, and those where excellent at their work because it was highly selective and you needed to be passionate. Now, programming is a mainstream job, which means that millions of people will do that as a day job without the ability nor the motivation.

        It's one of the side effect of massive growth. The few interesting guys of a specific domain get surrounded by many mediocre guys that just don't give a shit. You can see that pattern in every single domain.

        Puttin

      • You're not old or wrong. The hipsters just discovered UNIX pipes/sockets and decided that they should give them a trendy name... I shit you not, meet etcd (to be fair, it's pipes with a few extras, but nothing worthy of a name because I guarantee this has been done in the last 40 years once or twice). https://www.youtube.com/watch?... [youtube.com]

        This is actually the problem I have with Design Patterns - not them in and of themselves; I don't think they needed names, but I'm okay with them having names. I came to figu

      • by gweihir ( 88907 )

        Indeed. These hypes live on the mistaken belief that you can get great value out of mediocre and relatively cheap people by just using the right magic development process. That does not work and never will. It is just another manifestation of the greed and stupidity so prevalent in society today.

        The fascinating thing is that even the Scrum manifesto says "Individuals and interactions over processes and tools" in first place. A warning that this is only a tool and will not magically make people perform much

      • More scaffolding means more jobs and more ways to obfusicate your actual worth to the team.
    • by Spaham ( 634471 )

      Sign you're doing it right : your site is offline 3 or 4 times a week.

  • You treat "Devops"/Agile philosophy like a buffet and choose those elements that you like and disregard anything you don't as potentially slowing you down. getting in the way, or thinking that you are "smarter" somehow and then wonder why you don't get the desired results.
    • Thinking that there's a magic methodology that you can follow to the letter without realising that every product, every project and every business is different.

  • Janice in accounting don't give a fuck!

  • What's DevOps? (Score:5, Insightful)

    by Art3x ( 973401 ) on Wednesday December 09, 2015 @01:37AM (#51086585)

    No, I haven't read the latest InfoWorld article submitted by snydeq. But I'm pretty sure that it fails to answer the question, what exactly is DevOps?

    buzzword-laden definition: just google devops and you'll find enough
    best-guess definition: Development and Operations working together
    low-budget definition: Development and Operations being the same person

    By picking the right companies (that is to say, low-budget ones) I'm happy to say I've been doing DevOps for over a decade!

    • Re:What's DevOps? (Score:4, Insightful)

      by Greyfox ( 87712 ) on Wednesday December 09, 2015 @01:44AM (#51086609) Homepage Journal
      Developers having to do operations and getting paid operators salaries. Kind of like how all the companies currently looking for "test automation engineers" require Python and C++ and really want a developer who will take a tester's salary.
      • by pci ( 13339 )

        We have a few "test automation" people floating around, their managers want QA people embedded on their development teams and they only want to do it was to have programming skills as a job requirement. As a bonus it is a developer position/salary.

      • This is the correct definition of a DevOp. Developers who have to do Ops, because there are none. Therefore a developer you try to code your way out of the manual slogging that is Operations.

        It seems to have evolved to mean operations automation, but generally due to a lack of operations staff.

        So tools like Chef, virtualization on an outsourced infrastructure, and heavy API use are not uncommon. Success usually requires folks who have operations experience and code skills. If you do it right, you get to

    • Actually, it's quite simple: DevOps is an ATTITUDE. Nothing more, nothing less.

      For Developers: No more: "It works on my machine, It's Operations' problem now".
      For SysOps: No more: "I won't automate it because then everyone can do it and I like job protection."

      That DevOps-attitude has a goal: Continuous Delivery. Automate your deployments, so you can deploy at any moment. Involve your developers in the monitoring proces, so they can get involved when things go wrong in production.
    • DevOps is treating infrastructure as development.

      You wouldn't let someone write java code without version controlling it - so version control your packer.io scripts and ansible scripts for building infrastructure.

      You wouldn't let someone manually compile their java code instead of using maven - so script and automate everything from your OS build, to your middleware install, to your build/deploy, to your testing.

      If you're a testing freak, you can add testing in there too - have automated validation of your

      • Thanks, that simple description has explained it better than any ambiguous Wikipedia article or newsreel I've seen.

        If I have had some mod points left I would have upvoted you instead of replying; this post deserves to be seen.

  • Devoops (Score:5, Funny)

    by sonamchauhan ( 587356 ) <sonamc@gma i l . com> on Wednesday December 09, 2015 @01:41AM (#51086595) Journal

    1. You fired all your operations people and gave developers pagers.
      --OR--
    1. You fired all your developers and gave your operations people compilers.

    • by Etcetera ( 14711 )

      1. You fired all your operations people and gave developers pagers.

      --OR--
      1. You fired all your developers and gave your operations people compilers.

      Bingo. Devops means talking to each other and walking in each others shoes a little. It does NOT mean that either side is dispensable, and it's certainly not a replacement for advanced skill-sets and knowledge in either domain.

      It's also not an excuse for not dealing with best practices on both sides. The fact that it compiles and you've successfully shipped a black box Docker that seems to pass the tests doesn't mean the internals have been properly designed and engineered, which means you've made fixing pr

    • by dargaud ( 518470 )
      As someone who has gone to Antarctica [gdargaud.net] to install and run the software I write, I can proudly say I've been doing Devops for decades ! And I just learned the term a minnute ago...
      • by KGIII ( 973947 )

        I've been to your site before! I recognize it from mousing over the penguin images and they yelled at me. It took me a minute to figure out how the squawking was being initiated the first time I visited. Now I think I know how I got there. I assume that I followed your signature or a link you posted. I might have just been looking for penguins, I guess, but that's unlikely.

        No, I have no real point but I do encourage folks to click your link and check out the penguins. I got distracted so I have no idea what

        • by dargaud ( 518470 )

          I got distracted so I have no idea what actually did there but, damn it, penguins!

          Penguins will do that to you...

    • by gweihir ( 88907 )

      Hehehehe, nice!

      And, after a bit of time you are wondering why both your infrastructure and your new software is getting worse and worse.

    • 3. You hire a college grad to do both the developer and the operations jobs, with the operations salary.
  • by Anonymous Coward

    Elite coders doing tactical shit no one else can.

    The name lends itself to good marketing and make belief.

  • "You are doing it wrong and need expensive consultants to learn to do it right."

  • From the article: "Above all, devops is a cultural philosophy".

    Looks like it is another buzz word like Agile. Based on my experience, Agile can be "Fragile" when the team is not committed on it. Beyond that, Agile can NOT be applied to a) large projects b) projects with lot of groundwork and c) dev stack that require long compilation/building process. Most Agile/Scrum projects I worked end up falling back to a semi "Waterfall" workflow while still doing some Agile stuff (which I happily coined "ScrumFall" a

    • by pci ( 13339 )

      In my work, I'm viewing DevOps as automating the interactions between the Dev and Ops teams. For years the two sides would blame each other for everything and work to prove whatever happened was the other guys fault because they didn't want "root cause" to be assigned to them. With the few projects we have the deployment and configuration tasks completely automated, if an application isn't working then the developers have to own up. If a deployment fails the prerequisites then the ops guys can't hide the fa

  • "Devops" is what you call developers if you can't afford to have dedicated operational staff.
    I just don't see why anybody would actually want a single person to take on conflicting roles.

  • From the article:

    If your company bought Chef or Puppet as a cure-all for its devops needs, you're doing devops wrong.

    The author hit the nail on the head here. Any company which puts in Chef or Puppet thinking this is a Silver bullet which will solve their lack of change management process and the hack-it-'till-it-works mentality is simply the wrong place for anyone with experience to work at, and the managers and the people who work there are clueless. Stay the hell away from such places, or you will regret being woken up at 02:00 in the morning because people hacked on stuff with Chef or Puppet, rather t

  • From the summary: "it can serve as great PR for bringing in great talent to your team"
    Really? Do you attract good developers by saying that you practice the latest and greatest buzzword? Anyone with half a brain knows to first of all investigate what the company in question _actually does_ before signing on and secondly, I think most people realize that none of these fancy methodologies are a silver bullet for being a great place to work. You need skilled developers and a management that realizes that these

  • I'm completely convinced the real long-term purpose of the Scrum/Agile methodologies is simply to further weaken any market competition naive enough to adopt it in the first place.

  • Or at least portions of it. Most of this thread seems to be authored by A.C., so it's hard to get a discussion going...

    That said: The one concept in the article about "continuously pushing code to production" sounds great, but I think it has serious limitations. Especially when coupled with the "don't be afraid to fail" concept. Perhaps for news aggregating websites or something that is fine, but you don't want to be developing safety-critical software that way.

    The things that are useful, perhaps, are th

    • by Cederic ( 9623 )

      As with most of these things, it's a balance.

      Continuous delivery on the home-grown intranet? Sure, go for it. Hell, Facebook do it on their mammoth shitfest.

      Continuous delivery to car ECUs? How about continuous delivery to the engine testbed, and keep the fire extinguishers primed.

      Even where you're putting a manual authorisation with specific checks and balances in place though, one that authorisation is given the rest should be automated. There's no point having thorough, extensive, durable, repeated and m

  • Re: #5, sometimes a failure is so egregious it's worth firing someone over. This should be measured not by the severity of what happened, though, but the dumbness or carelessness of the mistake that allowed it to happen.

    Re: #6, sometimes it's right to assign blame. That doesn't mean you rake that person over the coals, but at the very least that person (and whoever has the authority to fire or promote him or her) should understand who is to blame.
    • by gweihir ( 88907 )

      ReRe: #5, but that would mean you have to fire _management_! Because they put somebody into a position where they were in over their head (I see that all the time...) and set them up to fail. Nothing more stupid than doing that. (Of course you need to fire the incompetent developer/tester/etc. as well.)

      ReRe: #6, this one is very tricky. Finger pointing usually does not result in any clear picture and quite often the people actually responsible manage to fly under the radar. While not assigning blame is a ba

    • by Cederic ( 9623 )

      I've known some very good managers who explicitly state that they will not ever fire anybody for making a mistake.

      Make it twice however..

      Even there though, root cause analysis. Is the developer lazy, or is this just within the reasonable bounds of human limitations and best addressed through a change in process, an authorisation, an automated test, additional training?
      Are Ops incompetent or making rational decisions that have bad outcomes because there are no good options available, focussing on a different

    • Number 5 are corollaries to number 4:

      At its heart, the agile methodology consists of releasing small changes as often as possible ... It is about defining what is considered "production ready," representing that with a set of automated tests, and trusting that the tests written correctly define what it means for code to be "production ready." ...

      For the true devops rock stars, it's also about taking that code and sending it directly to production through continuous deployment. If your company allows developers to check in code that goes through automated pre-check-in tests, gets handed over to another set of tests to ensure that the code is ready for production, then goes live on your production servers if deemed ready automatically, then you know you've achieved devops greatness.

      If your organization really believes that automated tests can find all show-stopper bugs, and that absolutely no man-in-the-loop soak testing is needed to find unexpected problems, then you are guaranteed to have these failures in ops rather than dev. At that point, you are either explicitly accept that you are treating your users/customers as alpha testers, or the blame is on whoever adopted that QA policy, not the person who introduced the bug.

  • You can have the Devs do Ops and so you don't need to hire any of those pesky Ops people. At least that is how managers see it. Saves time! Saves money! Agile! Buzzword compliant!

    Basically as I read up on DevOps I found I had been using it for years. Except I called it "running a professional software development shop where everyone works together to meet goals". Of course "DevOps" looks better on a book title or as the title of a blog post.

    • by Cederic ( 9623 )

      Except I called it "running a professional software development shop where everyone works together to meet goals"

      That'll never work! Why, if it did everybody would be doing it.

      To be fair, I'd settle for people even bloody trying..

  • We violate half of the seven items on the list. Oh well.
  • But in truth, many companies — and technical recruiters — that are proclaiming their devotion to [ANYTHING AT ALL] from the hilltops aren't really [ANYTHING AT ALL] organizations."

  • You're doing devops.

Real Users hate Real Programmers.

Working...