Slashdot Mirror
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."
Expecting "Devops" to be a panacea and the answer to every issue you face.
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!
1. You fired all your operations people and gave developers pagers.
--OR--
1. You fired all your developers and gave your operations people compilers.
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.
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.