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

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."

Comments

Sign #8

[offa]

Expecting "Devops" to be a panacea and the answer to every issue you face.

Re:Sign #8

[Anonymous Coward]

s/devops/scrum/g

Re:Sign #8

[l3v1]

They are, still, it's a valid answer to "Expecting "Devops" to be a panacea and the answer to every issue you face."

Sign #9

[offa]

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.

Re:Sign #9

[KGIII]

I'm glad you asked... I could preface this with a long-winded history but I'm going to skip that (this time) for the sake of brevity (really). Well, I'm going to *try* to be articulate.

I started programming because I had a need to. I did this for quite some time along with a Comp Sci grad who was my first employee but he didn't do as much of the programming as one might think -- he had other things to do as we were really pushing the hardware further than it was meant to go. Imagine, if you will, the 1990s and, by the end of the 1990s, we were working with data sets that were nearly a TB in size and spread out over giant disk arrays.

Anyhow, the business grew. This meant that my time was severely constrained. I was putting in 20 hour days, often for weeks at a time, and sleeping in the office. This could not last and eventually I hired competent people who were skilled in the mystical art of programming. They were far more adept than myself and much quicker. They were expensive but worth it. They even went so far as to re-write the entire code base because, "Code comments go in the code, not on a coffee stained index card on your desk, asshole!" (That's pretty close to verbatim.)

Now, we didn't have a name for it and I don't know if there is a name for it. But, I tried micromanaging and I tried to keep up and to keep things directed, I really did. I tried to be involved in every commit and every push to production. I tried to understand the new complexity and the new functions when, really, all I needed to do was help them tweak algorithms and help them learn to automate data manipulation tasks. I was still putting in 20 hour days.

Then, I realized I'd hired them for a reason. I'd hired them because they were the best in their field. I hired them because they knew what they were doing and were better at it than I was (which is not a hard task, let me assure you). I paid them very good salaries and gave them great benefits because they were keeping my company afloat and enabling us to expand exponentially. Yet, I wasn't really letting them do their job to the best of their ability.

See, I learned to shut the hell up and get out of the way. Now, I suspect there's no "Shut the fuck up and listen to smart people" mode of development but I can tell you that it is quite successful. I gave them clear directions. They told me what they needed. They told me when it would be done. I gave them the tools they asked for, not the ones a vendor suggested, and shut the hell up and got out of the damned way.

In the interests of brevity, it worked. I am where I am today because of them and because of my being willing to set my ego aside and accept that I'd hired people for a reason. It was hard, this was my baby. No, seriously, it was damned hard to let go. Now, I don't know what they did internally but it looked like they took directions, planned, and then executed. The difference is, they were given what they said they needed, rewarded for their effort, and had a vested interest in success. They didn't have a leader, a supervisor, or anything like that. They had a goal, picked what they did best, and worked on it until it was done.

I don't know what you call it but, well, hire smart people and pay them well. Let them do what you hired them to do. Give them help when they need it. Give them the tools they ask for. Give them a reason to KNOW that they can screw up. Be willing to screw up and admit your errors and learn from them yourself. Treat them like adults and they'll sort out who does what and when - all on their own and without any input from you beyond giving them direction. If they can't then you hired the wrong people.

So, yeah, thanks for asking. That's what worked best for me. Try it sometime. It means letting go of your ego, it means being willing to admit you're wrong, and it means treating people like adults who deserve to be rewarded for hard effort and earn a decent living. It means being smart enough to know what you don't know and being willing to ask someone who does

Re:Sign #9

[KGIII]

I am, quite happily, retired. I sold out about eight years ago and I sometimes miss it but I'm never really unhappy with my choice. The thing is, it doesn't seem like this is a difficult thing to figure out. I mean, hell, I managed it. I'd never taken a single business course in my life. I'm a mathematician, not a manager or a business graduate. The hardest thing was letting go, emotionally, and learning to listen to smart people. I don't know everything. I can't. If I need those skills then I should get the best person I can to provide them and then listen to them when they tell me what needs to be done. Otherwise, why hire them?

It was definitely a life-changing event. Or, more accurately, a series of events. I certainly did not expect to be where I am today. I expected to be in academia somewhere, maybe at an old rustic New England university, and driving an antique Saab to work while I lived in a fixer-upper house from the turn of the 19th century. But, life throws you strange chances and, if you dare, you can try to take advantage of those things and do something different. I was lucky and happened to be in a position where I was able to take risks and then capitalize on it.

I think that, in particular, was probably what led to the above mentioned management style. "Buggered if I know? That's why I hired you. Tell me what you need and I'll get it for you." Also, I've no moral qualms about poaching good employees, training them, or even sending them to school if they show talent. There weren't a whole lot of traffic engineers at the time and most of them were in fleet management, things like mine vehicular flow management, or dealing with choo-choo trains. Damned right I'll pay for good talent and pay to train someone or cross-train someone who has an aptitude.

Then again, I sometimes wonder if it was that I didn't have the preconceived notions and I had no idea how to manage people "by the book" that made it work? They weren't employees. They are people without whom the business would have been impossible. Sure, we sometimes made errors and had to crunch to meet deadlines but, yeah? We buckled down and did it. Maybe management school would have killed that. I don't really know.

I'd probably write a book detailing my experiences and lessons learned but I doubt anyone would read it and actually listen to it. I do, sometimes, hope there's a manager or two on Slashdot that reads these responses from people like you. They won't listen to me but they might listen to you and understand that it impacts you in a meaningful fashion and that also impacts the bottom line. Not to mention, from the way some of you folks describe it, it must suck to be a "human resource." Even when we finally had over 200 employees, we didn't have an HR department. I kind of find the idea appalling.

What's DevOps?

[Art3x]

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?

[Greyfox]

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.

Devoops

[sonamchauhan]

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

Re:Devoops

[Etcetera]

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 problems and dealing with fires (traditionally the domain of the SysAdmin/SysEng, but they'll wake up a Dev if they have to) much more difficult. Frontloading complexity into your automation framework doesn't make anyone's life easier except the person doing the most rote of tasks. The equivalent is making a nice, shiny, impossible-to-repair car that's nothing but code spaghetti and mush underneath the hood because you didn't have a human sanity-checking what you put out.

Can anyone keep up all these bullshits?

[Taco Cowboy]

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

Re:Can anyone keep up all these bullshits?

[mfearby]

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:Can anyone keep up all these bullshits?

[arkhan_jg]

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 firefighting all the time because devs just frack it up even worse now they push direct to production; then it's just another bullshit buzzword.

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.

I'm a traditional sysadmin, but I've brushed up on my coding from my undergrad days the last couple of years, and have a couple of my own projects deployed now. I work pretty closely with our 3rd party developers, so can understand and support their requirements better, and they work with me rather than round me. Is that devops? I dunno, but it beats the hell out of the usual silo'd suspicion and blame game.

Re:Can anyone keep up all these bullshits?

[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 tricky bits of a project is to hack out a quick prototype to see if what you've got on paper is gonna make sense in code or pick up on realities you might not have accounted for. Especially true when interfacing with other hardware/software/services, because what the spec says and what the thing does often don't line up perfectly, and fixing the "thing" isn't always an option.

Re:Can anyone keep up all these bullshits?

[goose-incarnated]

badly run agile,

You repeat yourself ;-)

Re:Can anyone keep up all these bullshits?

[Big Hairy Ian]

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 presented with the spec written on a rubics cube which has been scrambled. Devops is simply extending this to the plug it in and see if it works approach to application maintenance :D

Re:Can anyone keep up all these bullshits?

[eulernet]

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.

Re:Can anyone keep up all these bullshits?

[JustAnotherOldGuy]

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.

Re:Can anyone keep up all these bullshits?

[THE_WELL_HUNG_OYSTER]

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. 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 familiar? Agile is just another one of them. It is not a paradigm shift.

Whoever said in an earlier comment that this is about money is right: all of these software engineering paradigms are money grabs. Doesn't mean they don't work for very specific projects in specific circumstances, but the primary goal is for the Tailors to sell the Emperor some New Clothes.

The bottom line is that there isn't any single software engineering/development process that works well for all organizations, for all projects, just like isn't a Unified Field Theory.