How to avoid getting hoodwinked by a DevOps hustler We’re almost halfway through this year, and how’s progress on those Digital Transformation Initiative slides doing? Maybe you need a quick jump in improvement to buy some time for August vacations, and then ensure you can get enough actual change and a few successful projects in place by the holidays. While they’ll ship …
I'm a programmer with some pretty nice notches on my belt. I'm into data center automation now. I spent 5 solid years establishing proficiency in IT since leaving product development and now am actively working on Powershell DSC and C#. I regularly write and open source modules and tools and work with customers ranging from a few dozen users to the largest government entities in the world. I employ test driven development, code review, unit and integration testing and revision control. I focus 100% on deploying systems that not only work, but repair themselves when things go wrong allowing operations and development work on implementing new systems instead of fixing things that shouldn't have broken to begin with.
I have absolutely no idea what DevOps is even though I'm a developer and my coworkers are operations.
I am certainly not an expert either.
So no... people don't know what it is and the people who are probably best at it are still just learning.
Let's summarize it as this.
If you're scripting... it's not DevOps
If you're doing it by hand... it's not DevOps
If you're describing what you want and then a system implements it and makes sure it stays implemented... it may be DevOps but since there are no reliable systems for that yet, it probably isn't.
"If you're describing what you want and then a system implements it and makes sure it stays implemented..."
Isn't that what Quality Assurance is supposed to be about?
Okay, I see. ISO9001 was horrible and your Quality Manual could be lousy and nonsense but that didn't matter so long as it was followed without deviation. Now I understand. All the chancers involved in Quality have rebranded themselves as DevOps, right?
Possibly the second most honest statement in this article and its comments.
The "experts" were doing this before it had a name.
The "experts" probably don't think what they do is anything like what people describe as "DevOps" so you won't find them in a "DevOps" conference.
There are always (by definition) damm few of them
@Ragarath
Has anyone figured out what devops is yet?
DevOps is a results-oriented, forward-thinking reimagining of interdepartmental synergistic methodologies for thought leaders that applies strategically empowered dynamic core principals to agile industry championing.
>You mean, it's a whole bunch of cobblers?
Please keep up. That's what we had before DevOps, who have now successfully transformed the organization by delivering a fully tasked holistic synergized aligned unified super-set of cobblers.
The #visibilitynotviability slack channel is just buzzing with emoji s.
Oh dear. I think I've just been sick in my mouth.
It's pretty simple.
Ops still isn't cheap enough for companies, so now they need to help write, debug and repair shit code in addition to doing all the infrastructure and security roles. The fact that Ops has no idea how to do this or time to do it in is not relevant to the discussion, since your boss has literally no idea what 90% of the people in Ops do and doesn't care to find out.
Meanwhile, developers were spending far too much time doing post-release support for their own high-quality code. Devops instead allows them to try and debug untested, appallingly-written pseudo-code put together by an overworked firewall specialist with 15 minutes of training in C#, which was immediately thrown into production because AGILE.
No, no, we're definitely doing this for the team's benefit, and not because it allows us to fire half of each team.
> Has anyone figured out what devops is yet?
Yes.[1]
Before devops, whenever developers completed a new app, it was put into Live by a process formally known as "throwing it over the wall". Occasionally you heard a howl of pain as it landed on someone and that was the only way you knew it had gone live (save for the bug reports!).
After devops, developers were kindly requested to shout "look out!" before throwing the app over the wall. In some really advanced companies, the ops guys come through a gate in the wall and collect the app. Maybe even hang around a bit to sit in on a stand up and hear how wonderful the app is from the developers themselves.
[1] Warning, may contain factually inaccurate statements, wild assumptions and some channeling of Verity Stob
I am not an expert, but here's my understanding:
DevOps has two parts to it. The first is just getting your developers and operations staff to talk to each other, without such colorful language as "those dirty bastards that wrecked my..."
The second part is about the workflow. Instead of "throwing it over the wall" as mentioned above, any sort of software change (either from devs or ops) goes into a semi-automated pipeline that culminates in the change being shipped as a patch. First the pipeline just makes sure the changes compile. Then it can try to integrate them, run any unit tests on them, and any other automated testing you've got. If it's passed, you should be pretty sure that the change is ok. So, you roll it out to a handful of test machines. Wait for a while, see if anyone complains. If not, roll it out to a larger set of test machines. Repeat a couple more times. If after all the testing, no one's complained, the change just automatically gets pushed to all your customers. If anything hiccups during the process, you roll back the change, find the guy that did it and make him fix it. Ideally, this means that every change to any part of the system gets a full inspection before it's shipped. It also means that you can continuously ship changes, rather than having to bundle them.
But, as I said before, IANAE.
If you catch them young and enthusiastic enough, yes: it can be made to work, really well. I've seen it and worked in such an org for a couple of years not that long ago.
Admittedly the level of clue in the org was way ahead of generic IT shops. The level of stupidity and ignorance even at the 'five years experience" level for generic sysadmin / engineer never ceases to amaze me.
</anecdote>
Snake Oil Salesman more like.
Selling the pot of gold at the end of the Rainbow.
Bah Humbug the lot of it. A total waste of money for 99% of the people seduced by this hokum.
I'll bet that a lot of them were also on the {Fr}Agile bandwagon and other bandwagons before that.
"ask the teams they work with if they’ve been helpful"
That isn't a thing. You demand that teams improve simply because you hired an expensive consultant, or bought an expensive software license, or moved everything to the cloud.
It is a proven fact (ask any consultant) that buzzword-related activity improves productivity, reliability, customer satisfaction and revenue! If you pay someone over the top to tell you what you should already know, you have to be consistently condescending towards your inhouse staff - you know, the people who actually keep your organisation running - who could probably have told you the same had you not pissed them off by giving the raise they were due for to some doughboy in a polyester suit whose primary raison d'être is to tell everybody They Are Doing It Wrong.
And if you want to know if putting the cart before the horse was a good idea, why not sign a contract, cross your fingers and hope for good news? You can always blame the horse for not pushing hard enough.
My company took a shot at the DevOps thing without knowing that is what they were doing. Well, those outside of IT did know know that is what they were doing. Ops hired a consulting company, who sent in a small team. IT worked with them, well tried to. Within 6 months the staff developers wanted nothing to do with maintenance, deployment support, answering questions... It was all about "just let us do it" and "we should build everything." 2 staff developers eventually quit after IT pushed back on not swallowing the DevOps pill. Another that would not let go of the idea eventually got canned.
If you asked any of those developers, they all really liked the "PM" aka DevOps guy, that was really neither. He was just a taskmaster. The reason they liked him is because he let them do whatever they wanted as long as they were working on something. The mess left behind is really something. Does the platform work, yes, until the times when it does not. When things go bad nobody has a clue as to what the cause could be because well, it was all about getting it out rather than making is sustainable. To make things worse, when the systems guys say it looks like the problem is related to "..." the DevOps team says "no, can't be." We know how that story usually ends.
“A strong background in not only the technical and tooling side of DevOps, but also in driving enterprise-wide people and process changes.”
Translation: "At least twice as long in $LatestFad ad $LatestFad has existed"
"Any organization that’s successfully changed is tripping over itself to tell others how awesome it went."
Translation: "Any organisation that's persistently chased rainbows to no good effect is ever going to admit to itself let alone anyone else that it's gone nowhere and will take any chance to boast how great it is".
I work for a consultancy. We promote agile practices. We promote DevOps.
I have worked in multiple teams where DevOps is a 'thing' and, hands down, they have been the most productive teams I have ever worked on.
What that means is that the team was responsible for the product. From building it to deploying it to supporting it. There were people on the team who specialised in operations as well as people who specialised in development.
However, everyone was responsible for everything.
Devs/Testers/Ops write code.
Devs/Testers/Ops deploy code.
Devs/Testers/Ops provide support in Live.
Where I have seen it not work is when the DevOps 'team' is just another team that exists between Dev and Ops. Instead of one wall, there are then two to throw things over.
These were multi-million pound accounts and led to the practices we put in place being used more widely within both companies.
"What that means is that the team was responsible for the product. From building it to deploying it to supporting it."
I find it scary that a product may have multiple teams working on different aspects of said product - that some build it, some other supports it... does everybody have to know the product inside out? Wouldn't it be better for the same team to know and support their own product?
Maybe that explains why there's so much awfulness going on right now with worms and hacks and other nasties. Too many people too disconnected from the software...?
Is that the team in the office where the walls are different colours, the floor is made of fifty shades of carpet and the ceiling is going to collapse under the weight of all the containers on top of it?
Hares are agile. Look what happened to them.
Mines is the one with Aesop's Fables in the pocket.
My team develops, tests, builds, deploys, and provides 24x7 production support for our app. We don't do server maintenance or user acceptance testing. Our tiny team is required to be Agile and DevOps this year.
So far Agile simply means daily scrums so we can look at the hours remaining on each task and how it figures on the burn down chart. It also includes additional record keeping by importing tasks into the Agile tool and tracking remaining hours, in addition to our actual enhancement tracker that contains all the details of what needs developed. The only guidance we have received on DevOps is that we need a test suite to do automated testing. And we were helpfully provided with a test tool designed to test web applications, and ours is a multi-tier winforms desktop app.
As someone who has been down the route of fabulous methodology of the year (RAD, JAD, ISO9001, KANBAN, Lean, 6 Sigma), Agile and DevOps (at least how they are being implemented where I work) don't pass the smell test. If management cannot provide concrete examples of the problems being addressed and the discrete steps the new methodology provides, then it's all smoke and mirrors.
In other words,
it is a pile of steaming dog poo who's smell intensity varies from company to company depending upon how much of the DevOps KoolAid that Management have swallowed.
Great for the MBA Management gobbledgook powerpoint creators but a total PITA for those at the sharp end who have to implement it in some half arsed underfunded way simply to meet some management wonks bonus target. Failure to meet these targets will mean that the whole IT team will be outsourced to India where no one asks questions let alone has the balls to argue with their bosses which guarantees total success before the MBA wonks move on to pastures new and rinse and repeat.
{see Icon because it is all bound to end in tears}
This isn't actually true. It takes a certain amount of skill to do slides well - at the firm I work at (well, attend from time to time) we have phalanxes of hot PowerPoint folk who can churn out slick presentations in seemingly zero time. Unfortunately that skill doesn't equate to being a good developer, or a good manager, or a good planner, or a good project manager, or good at anything to do with IT really. It usually does equate to being a bit of a twat.
I, for one, have never in my entire life, met a single person who "relied on Power Point" who wasn't completely superfluous to the organization. As a consultant, if a middle-manager is introduced to me as "our Power Point expert", that manager is usually the first to be fired. The second to go is anyone who claims to need said PP presentation. Power Point has wasted more man-hours, more CPU cycles and more meeting-dollars than any other line of purely corporate bullshit that I can remember in my well over a third of a century of trying to teach Corporate America to work efficiently with computers.
We witness the multiple passings of each new fad - sorry! - exciting new development and operational deployment methodology. Each, in turn, offering vastly improved, um, improvement into the bin when the next comes along.
Communication, expectations, resource allocation, responsibility, accountability and adherence to policy and procedure are and were addressed by Waterfall, SDLC, Spiral, SSADM, V-model, RAD, JAD, ISO9001, KANBAN, Lean, 6 Sigma, Agile and DevOps. Where it breaks down is the lack of initial planning and documentation, or adherence to process.
BS artists flourish in an environment of confusion, miscommunication and lack of accountability. Those in charge can blame the consultant for the failures and enjoy some darn awesome PowerPoint presentations.
Who cares? Why waste valuable brainpower trying to discern scarce pearls of wisdom from a slurry of marketing drivel designed to open the wallets of clueless executives? If you're any good at IT, you already know what Good Looks Like, you know that you don't need to spout the latest fatuous buzzwords in order to deliver results, and you *also* know that your organisation, and specifically its management, are the principal obstacles to making a good job of anything that's practical, cost-effective and has long-term usefulness.
By the time you've distilled a few pearls from the latest over-hyped jargon—and then sat there grinding your teeth thinking "That's IT?! All those words and slides for a few principles that all the useful folks have known forever anyway, stuff so obvious we don't even talk about it?"—you'll realise that "DevOps" is sooo yesterday, and the marketurds have coined a new catchphrase to disguise another old wheeze dressed up in the tawdry verbiage of the Latest Brilliant New Fad.
I daresay I'm not the only old curmudgeon who remembers seeing his first computer back when such a thing had its own air-conditioned, sizeable room in a university, and a remote connection involved a modem the size of a breezeblock with an actual socket to receive a telephone handset, curly cord and all. So I won't be the only one who produces a deep sigh and eye-roll when some incredibly earnest young professional (or worse, a sales-lizard) expounds the virtues of Innovatively Innovated New Innovation, replete with acronyms, backronyms and even crapronyms, giddily aslosh with the Kool-Aid of freshly-printed marketing nonsense, somehow remaining stubbornly unaware that what's needed today is exactly what was needed 50 years ago: practical, knowledgeable, experienced people who perceive and understand technology as tools to get stuff done—and know how to use them to do it.
Put by way of example—and getting personal now—introducing DevOps to your airline's IT will not wreak a magical transformation within an under-resourced, badly-run technology department full of demoralised employees in a company whose perpetually terrible management has spent 30 years treating IT as a deeply begrudged cost sink instead of the leading, competitive enabler it manifestly should be. Your mortal problems extend so far beyond gluing three-letter words together that it isn't even funny.
I have no idea if real DevOps experts exist. I suppose they do somewhere, but my personal experience has been more on the side of seeing these guys walking around with their head shoved so far up their asses they can see through their belly buttons - when I was in the service we called this posture "having a glass stomach"
What do you do if you're bosses have imbibed the LSD-laced Koolaid and you've got to get rid of one of these guys, and you're only in the middle? Well, one PhD physicist that has been mentoring me provided a perfect example of how to yank the DevOps' guys eject handle:
Wait for a viewgraph to come up in all its vomitous glory discussing how much DevOps will improve productivity. Note the number of significant figures quoted; in this example it was three sig fig. Doc then switches to his heavy hispanic accent (so as to be underestimated) and turns on the suck up, "Very impressive, sir! I see that you have improved productivity 32.2%. How do you do it?"
Puffed up, our DevOps guy then dumps another steaming load on the audience.
Doc, accent gone, then says, "Thank you. What I meant is this: how SPECIFICALLY do you measure productivity to a precision of three significant figures? What data do you use to support this? What is the uncertainty in your estimate? What metric constitutes productivity? .... "
Five minutes later, the kill, "Sooo... you think that you can walk into a room full of technical professionals, some with advanced degrees and randomly pull a number out of your ass and present it. Interesting."
Never saw the consultant again. Left that day driving like a bat outta hell.
"When asked for a lengthy list of referrals, if a prospective consultant pleads that their past dance partners are unwilling to talk, be immediately suspicious." -- Not so much unwilling to talk, as still sulking that I left and refusing to return my calls or provide any contact details. Those that do respond like to say refer to HR, but then cant give contact details for HR. Or HR cant assist because your manager has left the company too. But then throw a wobbler when they cant get any references themselves. HR teams need to sort their shit out
Devops, as practiced by my current "dance partner," means putting up posters with buzz words, giving some tech illiterate kids a crash course in project management and agile speak & then telling them to run scrums, rather than project meetings. The actual work & work flows stays the same - just using the likes of Trello & Slack instead of MS Project & emails. D'oh !
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
