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

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.

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?

[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: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